VSCode默认不自动检测无BOM文件编码，老.txt/.bat乱码因Windows记事本保存为GBK而VSCode按UTF-8解析；手动选Reopen with Encoding→GBK可验证，Save with Encoding→utf8可彻底转码；files.autoGuessEncoding开启后仅首次打开触发启发式猜测，对短文本或混合编码准确率低。

VSCode 默认不自动检测文件编码，所谓“自动识别”只是对带 BOM 的文件做精准匹配；无 BOM 的 GBK/Big5 文件必须手动干预或开启 files.autoGuessEncoding 才可能被猜中。

为什么点开老 .txt 或 .bat 就乱码

Windows 下记事本保存的中文文本默认用 GBK（无 BOM），而 VSCode 默认按 utf8 解析——二者字节序列不兼容，直接显示方块或问号。这不是文件损坏，是解码器用错了。

• VSCode 优先信任文件上次打开时你选的编码，哪怕你改了全局 files.encoding，它也照旧用旧编码读取
• 右下角编码名旁出现锁图标 → 表示该文件已被“手动确认”，settings.json 配置对其完全失效
• BOM 是唯一能 100% 触发自动识别的依据；UTF-8 with BOM、UTF-16 LE 等都能被立即识别，但纯 UTF-8（no BOM）和 GBK 都没这个待遇

files.autoGuessEncoding 开还是不开

开启后，VSCode 会用 jschardet 对文件内容做一次启发式扫描，仅在首次打开时触发，并在状态栏给出候选编码列表（如 GBK、Windows 1252）。但它不是实时监听，也不强制切换。

VSCode

避免常见的 VSCode 错误——设置冲突、调试器配置和扩展冲突。

下载

• 开：适合个人项目或小团队，能减少 70% 的手动重开操作；但对短文本（
• 关：大型工程或 CI 环境更稳妥，避免因误判导致内容二次损坏；尤其当文件含特殊符号（如 emoji、数学符号）时，autoGuessEncoding 容易把 UTF-8 错认成 ISO-8859-1
• 值必须写 true 或 false，不能写字符串 "true"，否则配置无效

怎么让 .txt / .log 默认用 GBK 打开

别配 "*.txt"，VSCode 不稳定匹配通配符；要用语言标识（language ID）方式，因为 .txt 默认归类到 [plaintext]，.log 多数也走这个通道。

• 在工作区 .vscode/settings.json 中加：

  "[plaintext]": {
    "files.encoding": "gbk"
  },
  "[bat]": {
    "files.encoding": "gbk"
  }
  

• [javascript]、[html] 等语言 ID 是官方支持的，优先级高于用户级设置，且只作用于当前项目
• 改完需关闭已打开的对应文件再重开，已加载的标签页不会自动刷新编码

乱码了，三秒内该做什么

别去翻设置、别删缓存、别重装插件。右下角点击编码名是唯一可靠入口，所有补救动作都从这里出发。

• 先点右下角编码名 → 选 Reopen with Encoding → 试 GBK、GB2312、UTF-8 with BOM（别跳过带 BOM 的）
• 如果菜单里没你要的，点 More... 手动输编码名，比如 Big5 或 Shift-JIS
• 显示正常后立刻按 Ctrl+S，再点右下角 → Save with Encoding → utf8，这才是协作友好的终局
• 若选项灰掉，说明文件未修改过，先随便敲个空格再删掉，让它变“已修改”状态

真正难处理的是那些既没 BOM、又曾被错误编码打开过、还被其他工具（比如 Prettier）在保存时强行转码的文件——这种得靠 Save with Encoding 强制覆盖，而且只能逐个来，没有批量捷径。