run code插件中文乱码因内置控制台默认cp936编码，需勾选“run in terminal”或配置pythonioencoding；change encoding插件转换易出错，须先确认原始编码再操作；files.associations不改变读取编码，应设files.encoding；中文语言包本身不干预编码，但系统区域+非utf-8模式会导致底层写入gbk。
Run Code 插件输出中文乱码，但终端正常
这是最典型的插件编码隔离问题：Run Code 自带一个轻量级控制台（非 VSCode 集成终端），它不读 terminal.integrated.* 配置，也不继承系统 chcp 设置，而是直接调用 Windows 的默认控制台 API，走的是 CP936（GBK）路径。
实操建议：
- 优先勾选插件设置里的
Run In Terminal选项——它会让 Run Code 直接复用你已配好的 PowerShell/CMD 终端，绕过私有控制台 - 若必须用插件内置控制台，需在插件配置中手动指定编码参数（部分版本支持
"code-runner.executorMap"中添加env字段，如{"PYTHONIOENCODING": "utf8"}） - 不推荐全局改系统区域设置来迁就插件，容易导致旧版 .bat/.reg 文件执行失败或路径解析异常
Change Encoding 插件批量转 GBK → UTF-8 时出错
该插件本质是调用 iconv 或 Node.js Buffer.toString() 做字节重解释，但它无法自动识别 BOM、混合编码或损坏的 GBK 字节流。常见错误现象包括：转换后出现 、中文变空格、文件末尾多出乱码。
实操建议：
- 先用右下角
Reopen with Encoding → GBK确认原始内容可读，再执行批量转换 - 避免对
.bat、.reg、.ini等系统脚本文件使用该插件——它们依赖 GBK 执行，转 UTF-8 后可能失效 - 转换后务必检查是否有 UTF-8 BOM（
EF BB BF），某些构建工具（如 Webpack）会因 BOM 报错；可用xxd -l 4 yourfile.js查看开头字节
files.associations 单独配 GBK 文件类型却无效
VSCode 的 files.associations 只影响语法高亮和语言服务，**不改变文件读取编码**。即使你写了 "*.txt": "plaintext"，VSCode 仍按 files.encoding 或 auto-guess 结果去解码，不会因为关联了类型就自动切到 GBK。
实操建议：
- 真正起作用的是
files.encoding+files.autoGuessEncoding组合，或配合右下角手动切换 - 对混编项目（如含 GBK 文档的 Python 工程），建议关闭
files.autoGuessEncoding，并在工作区.vscode/settings.json中按需覆盖："files.encoding": "gbk"仅对特定目录生效 - 不要指望插件能“智能识别”文件真实编码——所有猜测都是概率性行为，GB2312/GBK/UTF-8-BOM 在无上下文时极易误判
中文语言包插件与编码设置冲突
中文语言包（Chinese (Simplified) Language Pack）本身不干预编码逻辑，但它会触发 VSCode 的 locale 检测机制。当系统区域设为“中文（中国）”且未启用 UTF-8 全局模式时，VSCode 内部某些 Node.js API（如 fs.writeFile）可能 fallback 到 CP936，导致新建文件写入即乱码。
实操建议：
- 语言包只需安装一次，无需反复开关；若界面突然变英文，执行
Configure Display Language命令并重启即可，不是编码问题 - 真正要防的是“系统区域设置 + 未启用 UTF-8 全局模式”这个组合——它会让 VSCode 在底层写入时悄悄走 GBK 路径，哪怕你界面上看到的是 UTF-8
- 验证方式：新建空文件 → 粘贴“中文”→ 保存 → 用
file -i（Linux/macOS）或certutil -hashfile your.js SHA256（Windows）查实际字节，而非只信右下角显示
编码问题从来不是单点故障，而是文件读取、内存写入、终端渲染、插件沙箱四个环节的链式反应。任何“一键解决”的配置都只覆盖其中一环，漏掉任意一环，中文就会在某个环节消失。最稳的做法，是把每个环节的编码行为显式写死，而不是依赖猜测或继承。
