右下角锁图标表示文件编码被手动锁定，vscode将忽略所有自动编码配置；解锁需点击编码名→reopen with encoding→选当前编码并取消“remember this encoding”；锁图标消失且编码变灰才算成功。
右下角带锁图标？那不是乱码，是编码被强制锁死了
看到乱码第一反应别急着改设置，先看状态栏右下角——如果编码名旁边有个?图标，说明这个文件已被手动指定编码并“锁定”。VSCode 会彻底忽略 files.autoGuessEncoding、语言级配置甚至全局 files.encoding，所有设置对该文件全部失效。
解锁方法只有一步：点击编码名 → 选 Reopen with Encoding → 再次选当前显示的编码（比如 GBK），**务必取消勾选“Remember this encoding for future files”**（不同版本文案略有差异，核心是“不记住”）。关掉文件再重开，如果锁图标消失、编码变灰，才算真正解锁。
常见错误现象：
- 改了
"files.autoGuessEncoding": true没反应 → 文件被锁，配置压根没生效 - 在 settings.json 里加了
"[plaintext]": {"files.encoding": "gbk"}，但某个 .txt 还是乱码 → 它已经被锁成 UTF-8 了
files.autoGuessEncoding 设成 "true" 就等于没设
这个配置项必须是布尔值 true，写成字符串 "true"（带引号）VSCode 完全静默忽略，行为等同于 false。JSON 里引号多一个少一个，结果天差地别。
它只在文件**首次打开时**触发扫描，已打开的乱码标签页不会自动重检；对纯 ASCII 内容（比如只有英文注释和空格的 .ini）基本无法识别 GBK；而且自动猜测对短文本、无 BOM 的纯中文文件成功率很低。
所以别指望它救所有旧文件。真要靠它，得满足两个条件：文件没被锁 + 首次打开 + 内容有足够特征（比如混有 ASCII 和中文、有常见标点或关键词）。
全局设 "utf8" 是给老项目埋雷
把 "files.encoding": "utf8" 直接塞进用户 settings.json，看似一劳永逸，实则会让大量 Windows 老文件（.bat、.reg、.ini、.txt）一打开就满屏方块——因为它们本就是 GBK 编码，且依赖系统级执行环境（比如 chcp 936）。
安全做法是用语言标识做精准覆盖：
-
"[plaintext]": {"files.encoding": "gbk"}—— 覆盖所有未识别语言的纯文本 -
"[bat]": {"files.encoding": "gbk"}—— 比"*.bat"更可靠，VSCode 对语言 ID 的匹配优先级高于后缀 - Python/JS 等代码文件仍走默认 UTF-8，不受影响；注释里的中文也能正常解析
注意：files.encoding 控制的是“保存时用什么编码”，不是“打开时用什么编码”。打开时优先看 autoGuessEncoding + BOM + 文件历史记录。
搜索（Ctrl+Shift+F）找不到乱码文件？它根本没被索引
VSCode 全局搜索默认只索引 UTF-8 编码的文件。哪怕你用 Reopen with Encoding 把一个 GBK 文件看得清清楚楚，Ctrl+Shift+F 也不会在里面搜出任何内容——因为它压根没被加载进搜索索引。
这不是 bug，是设计使然。目前没有开关能打开对非 UTF-8 文件的全文搜索支持。如果你要查老项目里的中文配置项，要么提前把文件批量转成 UTF-8（用 iconv 或 Notepad++），要么换工具（如 ripgrep 加 -e 指定编码）。
最容易被忽略的一点：终端输出乱码和编辑器乱码是两件事。你在集成终端里跑 Python 脚本看到“文件”，问题大概率在 terminal.integrated.env.windows 或系统 chcp 设置，跟 files.encoding 无关。
