应点击右下角编码名选Reopen with Encoding依次尝试GBK、GB2312、UTF-8 with BOM、UTF-8，中文立即正常即为真实编码；确认后须Save with Encoding→UTF-8（非with BOM）覆写文件，并设"files.autoGuessEncoding": false和"files.encoding": "utf8"确保稳定。
怎么识别文件真实编码而不是靠猜
VSCode右下角显示的UTF-8或GBK只是它“以为”的编码，不是文件真实编码。点状态栏编码名后，优先选Reopen with Encoding，而不是直接改设置。依次试：GBK（Windows记事本默认）、GB2312（老系统导出）、UTF-8 with BOM（Excel/Notepad++导出CSV常见）、UTF-8（新项目标准）。只要中文立刻变正常，就说明找对了——这个操作不改文件内容，安全可逆。
保存时强制转成UTF-8但避开BOM陷阱
能看≠已修复。只靠Reopen with Encoding是临时解码，下次打开还可能乱。确认显示正常后，再次点击右下角编码名，选Save with Encoding → UTF-8。注意：必须选UTF-8，不是UTF-8 with BOM；后者在Python/Shell脚本里可能引发SyntaxError: Non-UTF-8 code starting with '\xff'。如果文件含特殊符号或注释混用，建议先复制内容到新文件再另存为UTF-8，避免转码污染原始结构。
禁用autoGuessEncoding防止误判
files.autoGuessEncoding开起来像省事，实际是隐患源头。短文本、纯数字+中文、无BOM的GBK文件，它常误判成ISO-8859-1或windows1252，刚打开就变乱码。在settings.json里加这一行："files.autoGuessEncoding": false，配合"files.encoding": "utf8"，让VSCode完全按你指定的规则读写，行为可预期。老项目混GBK？别全局硬设，改工作区.vscode/settings.json单独配，或用插件按后缀识别。
终端输出乱码不能只靠chcp 65001
在终端输chcp 65001确实能临时切到UTF-8，但每新开一个终端都得重输。更稳的做法是在settings.json里配terminal.integrated.profiles.windows，给PowerShell或CMD加启动参数："args": ["-NoExit", "/c", "chcp 65001"]。但要注意：这仅解决终端渲染，不改变程序自身的stdout编码。比如Python脚本，还得加sys.stdout.reconfigure(encoding='utf-8')；C程序则需确保setlocale(LC_ALL, "")生效且系统区域支持UTF-8。否则即使终端设对了，程序输出仍走GBK通道。
真正难处理的不是单点配置，而是多层编码链：文件保存编码 → VSCode读取逻辑 → 终端代码页 → 程序运行时locale → 字体字形映射。任一环节断掉，中文就卡在方块或问号里。动手前先分清：是编辑器里看不到，还是终端里print不出来，或是Git diff里路径变成\344\270\255\346\226\207——它们对应完全不同的修复层。
