批量替换不导致乱码，真正问题是编码未正确识别就保存或误用命令覆盖原始字节；必须先reopen with encoding确认显示正常，再save with encoding转码。
批量替换本身不会导致乱码，真正出问题的是：在编码未识别正确前就执行了保存操作，或者用错命令把已错解的字节流二次写回磁盘。所有“批量替换后变乱码”的案例，本质都是编码状态被污染了。
Reopen with Encoding 必须在 Save with Encoding 之前做
这是最常踩的坑——很多人打开一堆 GBK 文件，看到满屏“锟斤拷”，直接右键 → Save with Encoding → UTF-8，结果所有文件永久损坏。
-
Reopen with Encoding只改内存视图，不碰磁盘，可反复试、零风险 -
Save with Encoding是真写磁盘，一旦选错编码，原始字节就被覆盖，不可逆 - 必须先对每个文件单独执行
Reopen with Encoding→Chinese (GBK)，确认中文正常显示，再点Save with Encoding→UTF-8 - 状态栏右下角显示
Chinese (GBK)才算成功；显示UTF-8却仍是方块字，说明还没识别对
ConvertToUTF8 插件在批量场景下默认行为是“假转换”
它名字叫“转 UTF-8”，但默认配置下 convert_on_save 是 true，意味着你 Ctrl+S 时，它会把内容按原始编码（比如 GBK）写回去——看起来没变，其实根本没转。
- 想让它真转成 UTF-8 并落盘，必须手动关掉
convert_on_save，只留convert_on_load开着 - 插件配置里
"encoding_list"必须显式写["Chinese Simplified (GBK)", "GBK"]，光写"GBK"不生效 - ST4 用户注意：
ConvertToUTF8自 2020 年起停止更新，Build 4126+ 后常见状态栏不刷新、右键菜单消失，建议换Codecs37 - 插件不解决“批量识别错误编码”问题——它仍可能把 UTF-8-BOM 文件误判为 GBK，尤其当
detect_encoding: true开着时
真正安全的批量转码必须绕开 Sublime 内部逻辑
Sublime 没有原生批量编码判断能力，任何“一键全项目转 UTF-8”的功能，背后都是调外部工具。自己搭一层命令行胶水，才可控。
- 先用
file -i *.txt（Linux/macOS）或 Notepad++（Windows）确认所有目标文件真实编码一致，比如全是charset=gbk - 建一个 Build System：
{"shell_cmd": "iconv -f GBK -t UTF-8 '$file_path/$file_name' > '$file_path/utf8_$file_name'"}，右键多个文件 →Build With，生成新文件而非覆盖原文件 - 别信
nkf或recode的自动检测：它们也容易把带 BOM 的 UTF-8 当 GBK，必须显式指定-f GBK - 大文件（>10MB）慎用 Sublime 批量操作——
max_detect_lines超过 1000 行后，插件检测慢且误判率飙升
fallback_encoding 配置写错等于没配
很多人在用户设置里写 "fallback_encoding": "UTF-8"，以为能兜底，结果发现 GBK 文件还是乱。这是因为 Sublime 的 fallback_encoding 不接受标准编码名。
- 正确写法只能是 Sublime 内部注册的标识符，例如：
"fallback_encoding": "Chinese (GBK)"或"Western (Windows 1252)" -
default_encoding才支持"UTF-8"，但它在 ST4 中已被弃用，只影响新建文件和另存为对话框 - 真正控制保存行为的是
default_encoding_on_save，设为"UTF-8"才能让 Ctrl+S 默认走 UTF-8 - 顺手加
"save_with_bom": false，否则 Python 和 Git 会报Non-UTF-8 code starting with '\xef'
复杂点在于：没有万能识别算法。混合了 UTF-8-BOM、GBK、GB2312、ANSI 的老项目，靠工具自动判断永远有漏网之鱼。最稳的方式，还是人工用 file -i 或 Notepad++ 看一眼真实编码，再决定怎么动。
