st4中utf-8 bom文件乱码或保存出错，主因是bom与gbk混用、插件与内置编码探测冲突、保存时默认加bom，需手动reopen为utf-8-bom再save为无bom utf-8。
为什么UTF-8 BOM文件在ST4里显示乱码或保存后出错
ST4 会把 \xef\xbb\xbf（UTF-8 BOM）识别为合法前缀，但部分场景下仍误判为“非 UTF-8”，尤其当文件混有 GBK 字节或 BOM 后紧跟非法 UTF-8 序列时。更常见的是：插件（如 ConvertToUTF8）与 ST4 内置编码探测逻辑冲突，导致加载时跳过 BOM 直接试 GBK，结果把本该正确解码的文件判成乱码。
Reopen with Encoding → UTF-8 失效？先确认BOM是否真实存在
右下角显示 UTF-8 ≠ 文件真带 BOM。很多“看似 UTF-8”的文件其实是无 BOM 的 GBK，只是碰巧能被 UTF-8 解一部分——关掉再重开就崩。验证方式必须落地：
- Linux/macOS 下运行
xxd 文件名 | head -n1，输出含ef bb bf才是真 BOM - Windows 用户用 Notepad++ 打开，右下角明确标 “UTF-8-BOM” 才可信
- 别信
file -i输出的charset=utf-8：它不区分有无 BOM，且对混合编码文件常误报
Save with Encoding → UTF-8 保存后仍报 Non-UTF-8 code starting with '\xef'
这个错误不是 ST4 读错了，而是 Python 解释器读到了 BOM 却没设 PYTHONIOENCODING=utf-8，或者 Git 认为 BOM 是脏字节。根本原因在 ST4 的保存行为本身：
-
"save_with_bom": false必须写进用户设置，否则默认true，每次Ctrl+S都悄悄加 BOM -
default_encoding_on_save设为"UTF-8"后，ST4 会强制按 UTF-8 编码落盘，但若原始文件是 GBK+BOM，它会把 BOM 当普通字节转义写入，导致开头变成\xef\xbb\xbf+ 原始 GBK 字节 → 双重乱码 - 真正安全的保存路径只有：先
Reopen with Encoding → UTF-8-BOM（确保视图正常），再Save with Encoding → UTF-8（注意选无 BOM 版本）
ConvertToUTF8 插件对 BOM 文件失效的典型场景
该插件默认启用 convert_on_load: true，但它依赖编码检测模块，而 ST4 的检测逻辑会优先信任 BOM —— 看到 \xef\xbb\xbf 就直接走 UTF-8 路径，不再触发 GBK 转换。所以它对纯 UTF-8-BOM 文件完全透明，但对“GBK 内容 + UTF-8 BOM”这种畸形文件反而失效。
- 遇到这类文件，插件状态栏可能显示
UTF-8，但中文仍是方块：说明 BOM 存在，但后续字节是 GBK，UTF-8 解码器已崩溃 - 此时必须手动干预：
Reopen with Encoding → Chinese (GBK)→ 确认显示正常 →Save with Encoding → UTF-8（无 BOM） - 插件配置中
"max_detect_lines": 1000和"confidence": 0.90对 BOM 文件无效，BOM 检测发生在首行，无需调参
