VSCode中文乱码主因是编码锁定与配置误写：右下角锁图标使所有设置失效，files.autoGuessEncoding必须为布尔true而非字符串，全局设"utf8"会破坏GBK依赖文件，搜索不索引非UTF-8文件。
VSCode 中文乱码不是“猜不对”，而是“没给它猜的机会”或“猜了但你锁死了结果”——关键在状态栏右下角那个带锁图标的编码显示，以及 files.autoGuessEncoding 的布尔值是否写对。
右下角编码旁有锁图标？配置再全也无效
这是最常被忽略的硬性拦截点。一旦你手动点过 Reopen with Encoding 或 Save with Encoding 确认过某文件的编码，VSCode 就会把它“锁定”，后续所有设置（包括 files.encoding、语言级配置、甚至 files.autoGuessEncoding: true）对该文件全部失效。
- 解锁方法：点击右下角编码名 → 选
Force Reload with Encoding（部分版本叫Reopen with Encoding再选一次当前编码），不勾选“记住此选择” - 验证是否解锁：关闭文件再重开，看状态栏是否恢复为灰色无锁状态
- 已锁定的文件不会因修改
settings.json而自动刷新，必须手动重开
files.autoGuessEncoding 设为 "true" 就是废的
这个配置项必须是布尔值 true，写成字符串 "true"（带引号）VSCode 完全静默忽略，不报错也不提示，但行为等同于 false。
- 正确写法：
"files.autoGuessEncoding": true - 错误写法：
"files.autoGuessEncoding": "true"（常见于复制粘贴 JSON 时多加引号） - 它只在文件首次打开时触发扫描，已打开的乱码标签页不会自动重检
- 对纯 ASCII 内容（如只有英文注释+空格的 .ini 文件）基本无法识别 GBK，别指望它救所有旧文件
老项目混 GBK，别全局设 files.encoding
强行把 "files.encoding": "utf8" 加进全局 settings.json，对新项目友好，但会让老 .txt、.bat、.reg 文件一打开就变方块——因为它们本就是 GBK 编码，且依赖系统级执行环境。
- 安全做法：用语言关联配置，例如针对纯文本类文件：
"[plaintext]": { "files.encoding": "gbk" } -
"[bat]": { "files.encoding": "gbk" }比"*.bat"通配符更可靠，VSCode 对后缀匹配优先级低于语言标识 - Python/JS 等代码文件仍走默认
utf8，不受影响；注释里的中文也能正常解析 - 终端输出乱码？那是
terminal.integrated.env.windows和系统chcp的事，和编辑器编码无关
搜索（Ctrl+Shift+F）根本看不到非 UTF-8 文件
VSCode 全局搜索默认只索引 UTF-8 编码的文件。哪怕你用 Reopen with Encoding 把一个 GBK 文件看得很清楚，Ctrl+Shift+F 也不会在里面搜到任何中文——它压根没加载进搜索引擎。
- 临时解法：先
Save with Encoding→UTF-8，再搜 - 长期方案：对必须保留 GBK 的文件（如某些 Windows 脚本），改用外部工具 grep 或 VSCode 插件（如
Search in Files+） - Git 提交前务必确认文件真实编码，否则
git diff显示异常、CI 构建报Invalid character ''都可能源于此
