vscode中文注释乱码主因是文件实际编码（如gbk）与编辑器解码方式（如utf-8）不匹配；应右下角点击编码→选reopen with encoding尝试gbk等验证，确认后ctrl+s保存，并在settings.json中按语言id精准配置files.encoding、禁用autoguessencoding，源头统一转utf-8。
VSCode 代码注释中文显示乱码，99% 不是字体或语言包问题，而是文件实际编码（如 GBK）与 VSCode 当前解码方式（如 UTF-8）不匹配 —— 你看到的“锟斤拷”“烫烫烫”或方块，就是字节被硬套错编码后的标准 fallback 表现。
怎么快速确认当前文件真实编码
右下角状态栏点击当前显示的编码（如 UTF-8），在弹出菜单中选 Reopen with Encoding → 依次尝试 GBK、GB2312、UTF-8 with BOM。一旦中文立刻可读，就锁定了真实编码。
注意：Reopen with Encoding 只是临时用该编码读取，不改变文件内容，也不影响下次保存行为。如果切完 GBK 能看，但 Ctrl+S 保存后下次打开又乱码，说明你还没把“保存动作”也对齐到 GBK。
- 切编码后务必手动按一次
Ctrl+S，否则修改不会落盘 - 若仍乱码，用
xxd your.c | head -n 3（Linux/macOS）或certutil -hashfile your.py SHA256（Windows）比对十六进制特征，比如D6 D0是“中”的 GBK 码，EF BB BF是 UTF-8 BOM - 老 Windows 项目常见
GBK with BOM，VSCode 会误判为 UTF-8，此时需选GBK或用 Notepad++ 去除 BOM
如何让特定类型文件默认用 GBK 打开和保存
全局把 files.encoding 设成 GBK 风险极高：JSON、.gitignore、Markdown、CI 配置全会崩。必须按语言精准覆盖。
打开命令面板（Ctrl+Shift+P），运行 Preferences: Open Settings (JSON)，加入：
{
"[c]": { "files.encoding": "GBK" },
"[cpp]": { "files.encoding": "GBK" },
"[java]": { "files.encoding": "GBK" }
}
- 如果是
.h文件乱码，把[c]改成[cpp]即可（VSCode 对.h默认归入cpp语言模式） - 不要写
"*.c"这类通配符——files.associations只控制语言模式，不控制编码；编码必须走[language-id]形式 - 加完保存，重启 VSCode 或重载窗口（
Ctrl+Shift+P→Developer: Reload Window）
为什么改了设置还是乱码？三个常被忽略的开关
很多人配完 files.encoding 仍失败，卡在这些隐性环节：
-
files.autoGuessEncoding设为true时，VSCode 可能在你手动切完编码后，又偷偷“猜回UTF-8”。务必在settings.json中显式关掉："files.autoGuessEncoding": false - Git 拉下来的文件，若
core.autocrlf和i18n.logOutputEncoding没配对，终端里git diff输出可能乱码，干扰你判断真实文件编码 - 文件开头有 BOM（如
UTF-8 with BOM）但内容实为 GBK，VSCode 会强制用 UTF-8 解析，结果必然错位 —— 此时需先用 Notepad++ 或iconv清除 BOM，再转码
真正省心的做法：统一源头为 UTF-8
靠每次手动切编码或给每个老项目配 [c] 规则，长期维护成本很高。一劳永逸的方式是批量把源文件转成 UTF-8，并确保所有协作者都用 UTF-8 保存。
例如用 iconv 批量转码：
iconv -f GBK -t UTF-8 your.c -o your_utf8.c
- 转完后检查注释是否正常，再用 VSCode 以
UTF-8保存（右下角点UTF-8→Save with Encoding） - 同时在团队
.editorconfig中加charset = utf-8，并设"files.encoding": "utf8"全局默认 - 特别注意：.bat、.reg、某些嵌入式 Makefile 仍依赖 GBK，这类文件不能强转，得单独保留在
[bat]规则里
最麻烦的不是操作步骤，而是得判断哪些文件真能转、哪些必须留 GBK —— 这个边界，往往要靠编译能否通过、脚本能否执行来验证，不能只看注释是否显示正常。
