应先选“通过编码重新打开”尝试gbk，若中文正常显示即确认原始编码为gbk；再选“以编码保存”改为utf-8（无bom）永久修复，切忌直接保存。
右下角编码显示点击后选“GBK”还是“UTF-8”？
看当前文件是否已乱码。如果打开就是方块、问号或错位符号，说明 VSCode 用错了编码去解码——大概率是它默认以 UTF-8 打开了一个实际为 GBK 编码的文件。此时应先点右下角编码区域，选“通过编码重新打开”，再依次尝试 GBK、GB2312、GB18030；一旦文字正常显示，就确认了原始编码。
切忌直接保存：此时若直接按 Ctrl+S，VSCode 会以当前显示编码（即刚选的 GBK）覆盖原文件，但文件内容字节没变，只是“标签”被强行改了——下次再用 UTF-8 打开仍会乱码，且可能损坏数据。
- 正确操作是：显示正常后，再点右下角 → 选“以编码保存” → 改成
UTF-8→ 保存 - 如果文件里有 BOM（如
UTF-8 with BOM），部分旧工具会误判，建议统一用无 BOM 的UTF-8 - Windows 记事本保存的中文文本，默认就是
GBK（或ANSI，实际等于GBK），这类文件最常踩坑
settings.json 里 files.autoGuessEncoding 开还是关？
默认开启时，VSCode 会扫描文件前几百字节，按统计特征猜编码。对纯中文文本有时能蒙对 GBK，但遇到混合英文、数字、符号或短文本（比如只有几行日志），极易误判成 windows1252 或 ISO-8859-1，反而导致乱码。
更稳的做法是关掉它，配合明确的规则：
- 在
settings.json中设"files.autoGuessEncoding": false - 用
files.associations按后缀指定编码，例如："*.log": "gb2312"、"*.ini": "utf8" - 对老旧项目根目录加一个
.vscode/settings.json，只作用于本项目，避免影响其他工作区
终端输出中文乱码，chcp 65001 不生效怎么办？
在 terminal.integrated.profiles.windows 里加 chcp 65001 是临时切换代码页，但有些情况它会被后续启动的 shell 覆盖，尤其是 PowerShell 启动脚本里有 Set-ExecutionPolicy 或调用了其他环境初始化逻辑时。
优先检查三项：
- 确认 VSCode 终端确实运行的是你配置的 profile：打开终端后，左上角标题栏应显示 “PowerShell” 或 “Command Prompt”，而不是 “Git Bash” 或 “WSL”
- PowerShell 需要允许执行脚本，运行
Get-ExecutionPolicy，若返回Restricted，需先执行Set-ExecutionPolicy RemoteSigned -Scope CurrentUser - 某些 Python 脚本显式设置了
sys.stdout.reconfigure(encoding='gbk')，会覆盖终端设置——这时得改代码，不能只调终端
插件自身读取配置文件时的编码陷阱
像 Change Encoding、File Encode 这类插件，其核心逻辑是调用 Node.js 的 fs.readFile。而 Node.js 默认以 UTF-8 读取文件，如果插件没显式传 { encoding: 'gbk' }，哪怕你在 UI 里点了“用 GBK 打开”，它底层仍是用 UTF-8 去读字节，再强行 reinterpret —— 这会导致双字节字符被截断，出现 。
所以别迷信插件一键转换按钮。真正可靠的批量转码，应该：
- 用命令行工具：如 Windows 下用
iconv -f GBK -t UTF-8 input.txt -o output.txt - 或写个简单脚本，用
fs.readFileSync(path, 'binary')读原始字节，再用Buffer.from(rawBytes, 'gbk').toString('utf8')转换 - 转换后务必用十六进制编辑器（如 HxD）抽查几个中文字符的字节序列，确认
UTF-8多字节结构正确（如“中”应为E4 B8 AD）
跨平台协作时，UTF-8 是唯一可预期的编码；但历史文件不会自动进化，手动验证字节才是最后一道防线。
