VSCode开启files.autoGuessEncoding仍乱码，因其仅首次扫描、不处理已锁定文件、对纯ASCII或短文本GB2312文件识别率极低，且配置写为字符串"true"会失效。
VSCode 默认不自动识别无 BOM 的中文编码文件，开启 files.autoGuessEncoding 是必要动作，但不是万能解药——它只在首次打开时扫描一次，且对短文本、混合编码或纯 ASCII 内容的 GBK 文件基本失效。
为什么开了 files.autoGuessEncoding 还是乱码
常见错误现象：勾选设置后打开老 .txt 或 .bat，状态栏仍显示 UTF-8，内容全是方块或问号。
- VSCode 优先信任该文件“上次手动确认过的编码”，右下角编码名旁有锁图标 → 表示已锁定，
settings.json配置对其完全无效 -
files.autoGuessEncoding: true仅触发于首次打开；已打开的乱码文件不会自动重检，必须手动点击右下角编码 → Reopen with Encoding → 尝试 GBK/GB2312/UTF-8 with BOM - 纯 ASCII 内容（比如只有英文注释+空格的老配置文件）无法被 jschardet 区分 GBK 和 UTF-8，猜测准确率趋近于零
- 值写成
"true"（字符串）而非true（布尔），配置直接失效，VSCode 不报错也不提示
怎样让 .txt / .log 默认用 GBK 打开
别配 "*.txt" —— VSCode 对通配符匹配不稳定，且优先级低于语言标识规则。
- .txt 文件默认归类为
[plaintext]语言模式，.log 多数也走这个通道；在settings.json中应这样写： "[plaintext]": { "files.encoding": "gbk" }"[bat]": { "files.encoding": "gbk" }- 注意：
files.autoGuessEncoding和语言级编码配置可共存，但一旦用户手动确认过某文件编码，语言级配置就不再生效 - 修改后需关闭再重开文件才生效，重启 VSCode 不是必须，但已打开的标签页不会刷新
全局开启 files.autoGuessEncoding 的真实代价
它不是“智能切换”，只是启发式扫描 + 状态栏候选提示，误判风险真实存在。
- 对含 emoji、数学符号或特殊控制字符的 UTF-8 文件，
autoGuessEncoding容易错判为ISO-8859-1，再以该编码重载会导致内容损坏 - 大文件（>50MB 日志）打开时会明显卡顿，因为要读取并分析前几万字节
- CI/CD 环境或自动化脚本中建议关掉，避免因编码误判导致构建失败或代码污染
- 若你依赖 ESLint/Prettier 等插件，它们可能在编码未明确时直接报
Invalid character ''错误，此时必须先手动指定编码再运行
最常被忽略的一点：VSCode 的搜索（Ctrl+Shift+F）根本不会索引非 UTF-8 编码的文件。哪怕你成功用 GBK 打开了一个 .js，里面明明有中文注释，全局搜索也永远找不到——除非先 Save with Encoding 转成 UTF-8。
