插件读取文件时默认使用文档当前 encoding 属性指定的编码（即右下角显示的编码），而非自行决定；若文件实际编码与 vscode 解析编码不匹配（如 gbk 文件被 utf-8 解析），插件获取的 document.gettext() 将返回乱码文本（如\ufffd），导致 eslint 报语法错误、prettier 格式化异常、gitlens 显示 unicode 转义等。
插件读取文件时默认用什么编码？
VSCode 插件（比如 ESLint、Prettier、GitLens）本身不直接决定文件编码，而是依赖 vscode.workspace.fs.readFile() 或 vscode.window.activeTextEditor?.document.getText() 这类 API 返回的文本内容。这些 API 的解码行为完全由当前文档的 document.encoding 属性控制——也就是你右下角看到的那个编码标识。
也就是说：插件看到的“中文”是否乱码，取决于你打开文件时 VSCode 用哪种编码解析了它，而不是插件自己选的。
- 如果文件实际是 GBK 编码，但 VSCode 用 UTF-8 打开，
document.getText()返回的就是一堆\ufffd（），插件拿到的就是损坏文本 - 如果插件调用了
vscode.workspace.fs.readFile(uri)，它会按文件真实字节读取，但后续转字符串时仍需指定编码；多数插件没显式传encoding参数，就走 Node.js 默认（通常是 UTF-8） - 部分插件（如 GitLens）会主动检测 BOM 或尝试 sniff 编码，但不可靠，尤其对无 BOM 的 GBK 文件
如何验证某个插件是否受编码影响？
最直接的办法是：打开一个已知乱码的文件（比如从微信粘贴中文后保存的 .py），然后在插件功能触发点（如保存时 ESLint 报错、光标悬停看类型提示）观察行为是否异常。
- ESLint 报
ParseError: Unexpected token，但代码明显合法 → 很可能是中文注释/字符串被解成 ，导致语法树断裂 - Prettier 格式化后中文变空格或方块 →
document.getText()返回了损坏字符串，Prettier 按原样重写 - GitLens 显示的 commit message 是
\u5f00\u53d1而不是“开发” → 插件没做decodeURIComponent或误判了原始编码
此时不要急着查插件文档，先点右下角编码 → “Reopen with Encoding” → 试 GBK / GB2312，能恢复显示再运行插件，基本就能确认是编码链路的问题。
插件配置里能强制指定编码吗？
绝大多数插件不提供“设置编码”的开关。它们的设计假设是：编辑器已经把干净文本交到手上。强行绕过 VSCode 的编码机制（比如让插件自己读文件+指定 encoding: 'gbk'）既不安全也不推荐——这会和编辑器状态脱节，导致光标位置错乱、保存冲突等问题。
- 唯一可控入口是 VSCode 自身的
files.encoding和files.autoGuessEncoding设置 - 某些插件（如 File Utils）提供“Save with Encoding”命令，本质还是调用
vscode.workspace.fs.writeFile()，底层仍依赖你当前文档的编码设置 - 如果你必须处理混合编码项目（比如老 VBScript 用 GBK，新 JS 用 UTF-8），用
files.associations单独配："files.associations": { "*.vbs": "windows1252", "*.js": "utf8" }
为什么改了 settings.json 还有插件乱码？
常见原因不是配置没生效，而是你改的是用户级设置，而工作区（.vscode/settings.json）里有更高优先级的覆盖项。
- 检查
.vscode/settings.json是否存在，并含有"files.encoding": "gbk"这类冲突配置 - 插件可能缓存了旧文档快照（比如 Language Server 启动时读了一次），重启 VSCode 或执行
Developer: Restart Language Server命令 - 某些插件（如 Python 扩展）会额外读取
python.defaultInterpreterPath对应解释器的 locale 设置，间接影响字符串处理逻辑
真正容易被忽略的是：插件看到的文本，永远是你当前文档“已解码后”的结果。修复源头（文件编码 + VSCode 解码方式）比折腾插件本身更可靠。
