根本原因是Sublime Text默认未启用UTF-8无BOM解码，而用系统编码（如GBK）读取UTF-8中文文件导致乱码；需修改Preferences.sublime-settings，设fallback_encoding和default_encoding均为UTF-8，并禁用detect_encoding。
Sublime Text 打开文件显示问号或方块字
根本原因是 Sublime Text 默认没启用 UTF-8 无 BOM 解码，而你编辑的中文文件恰好是 UTF-8 编码（但带了 BOM 或不带 BOM 都可能触发），它却用系统默认编码（比如 GBK）去读——结果就是乱码。这不是文件坏了，也不是插件问题，是解码策略没对上。
- 先确认乱码文件的真实编码：
file -i 文件名（Linux/macOS）或用 VS Code 右下角看编码标识 - 临时修复：菜单 File → Reopen with Encoding → UTF-8，如果显示正常，说明就是编码识别失败
- 别点
Convert to UTF-8，那会改文件内容；Reopen with Encoding只改当前视图解码方式，安全
设置默认解码为 UTF-8（含 BOM 兼容）
手动每次选太累，得让 Sublime 启动时就按 UTF-8 解码所有文件。关键是修改 Preferences.sublime-settings，不是安装插件。
- 菜单 Preferences → Settings，右边用户配置区加这两行：
"fallback_encoding": "UTF-8", "default_encoding": "UTF-8"
-
fallback_encoding是“当检测不到编码时用啥”，default_encoding是“新建文件用啥”，二者都设成 UTF-8 才稳 - 删掉配置里可能存在的
detect_encoding: true —— 这个开关反而会让 Sublime 误判 BOM 或跳过 UTF-8 尝试
GBK 文件在 UTF-8 环境下打开仍乱码
有些老项目文本是 GBK 编码，硬设默认 UTF-8 就会出问题。Sublime 不支持自动编码探测，只能靠人工干预或规则匹配。
- 单文件处理：右下角点击当前编码（如
UTF-8），选Chinese (GBK)→ 立即重载 - 批量识别：装插件
EncodingHelper（非必须，但比手动快），它能在状态栏显示真实编码并一键切换 - 别信“自动识别插件能 100% 准确”——GBK 和 UTF-8 的部分字节范围重叠，纯靠字节猜必然有误判，尤其短文本
保存时意外变成 UTF-8 BOM 导致其他工具报错
某些构建工具、Python 解释器、Git diff 会把 UTF-8 BOM 当垃圾字符，报 SyntaxError: Non-UTF-8 code starting with '\xef' 这类错。
- 关掉 BOM：在用户配置里加
"ensure_newline_at_eof_on_save": true不够，还得加"save_with_bom": false - 验证是否生效：保存后用
xxd 文件名 | head -n1，输出不含ef bb bf就对了 - 注意：Windows 记事本生成的 UTF-8 文件默认带 BOM，Sublime 若设了
save_with_bom: true，再保存就会“传染”给其他文件
真正麻烦的是混合编码项目——同一目录下既有 UTF-8 无 BOM 的新脚本，又有 GBK 的旧配置。这时候不能只靠全局设置，得配合右下角手动切编码，或者用项目专属配置绑定编码规则。这点容易被忽略，等 Git 提交失败才反应过来。
