先确认是文件编码错：编辑器注释乱码但终端和markdown预览正常，右下角点utf-8选reopen with encoding→gbk若恢复，即为gbk编码；再按语言类型配files.encoding:"gbk"，不可全局硬设。
VSCode显示中文注释乱码，90%不是插件或字体问题，而是文件实际编码（如GBK）和VSCode当前读取编码（默认UTF-8）不匹配——改“文件关联编码”能一劳永逸，但必须配对语言类型，不能全局硬塞。
怎么确认是文件编码错，而不是终端或字体问题
先看现象：只有编辑器里注释变方块/问号/\u4f60\u597d，而终端print("中文")正常、预览Markdown中文也正常——这就锁定是文件解码环节出错。右下角点编码名（比如显示UTF-8），选Reopen with Encoding → GBK，中文立刻恢复，说明文件确实是GBK，VSCode只是读错了。
别试files.autoGuessEncoding：它对GBK基本无效，反而可能把短文本误判成latin1，越开越乱。
为什么"files.encoding": "gbk"不能直接写进全局设置
全局设死"files.encoding": "gbk"会导致所有新文件（包括.py、.json）都用GBK保存，Python 3 会报SyntaxError: Non-UTF-8 code starting with，Git diff 出现大量\344\270\255转义路径。
真正安全的做法是按语言类型绑定编码：
- 打开命令面板
Ctrl+Shift+P→ 输入Preferences: Configure Language Specific Settings - 选中当前文件的语言（如
Python、Plain Text、JSON） - 在弹出的
settings.json片段里加："files.encoding": "gbk"
这样只影响该语言后缀的文件，.py走GBK，.js仍用默认UTF-8，互不干扰。
files.associations和语言专属设置的区别
"files.associations": {"*.bat": "gbk"}是“按后缀匹配”，适合无明确语言标识的文件（比如build.bat、config.reg）；而语言专属设置（如为Python配gbk）优先级更高，且能继承语法高亮、格式化等能力。
常见踩坑点：
-
files.associations里的键必须带*和点，写成"bat": "gbk"无效 - 如果文件没后缀（如
Makefile或无名配置），VSCode可能识别为Plain Text，这时要专门给Plain Text配编码 - 某些语言（如
ShellScript）在VSCode里对应的名字不是shell，得查真实语言ID：右键文件 →Change Language Mode→ 看底部状态栏显示的名称
改完设置后，旧文件还是乱码？这是正常现象
语言专属设置只影响“下次打开”，不会重载已打开的文件。关掉再重开，或按Ctrl+K Ctrl+R强制重载当前文件。
更关键的是：这个设置只管“怎么读”，不管“怎么存”。如果你希望后续保存也用GBK，得额外加"files.autoSave": "onFocusChange"并确保右下角始终显示GBK——否则Ctrl+S时仍可能按UTF-8写入，导致协作时别人又乱码。
复杂点在于：同一个项目里，.py文件可能是UTF-8（新写的），而readme.txt是GBK（老文档），硬统一编码反而破坏兼容性。这时候宁可手动Reopen with Encoding，也别强推自动配置。
