VSCode插件读取文件时默认使用编辑器当前判断的编码，由files.encoding、autoGuessEncoding及BOM共同决定；插件应调用vscode.workspace.openTextDocument().then(doc => doc.getText())获取已解码字符串，而非fs.readFile。
VSCode插件读取文件时默认用什么编码
插件本身不决定编码，它依赖 VSCode 提供的 TextDocument API 读取内容——而该 API 的解码行为完全由编辑器当前对这个文件的编码判断结果决定。也就是说，插件看到的文本是否乱码，取决于你对这个文件设置的编码（files.encoding）、是否启用了 files.autoGuessEncoding、以及该文件是否有 BOM 等元信息。
常见误区是以为装了“GBK 支持插件”就能自动识别 GBK 文件，其实多数插件只是加了个右键菜单或快捷命令，底层仍走 VSCode 原生解码流程。真正影响插件行为的是 VSCode 的编码配置，不是插件自己设的规则。
哪些插件会偷偷改编码设置
部分工具类插件会在后台启用或覆盖编码相关配置，典型表现是：你刚关掉 files.autoGuessEncoding，重启后又变成 true；或者新建文件右下角显示 “Auto” 而非 “UTF-8”。已知有这些行为的插件：
-
File Utils：默认开启 auto-guess，且其设置项优先级高于用户 settings.json -
GBKtoUTF8：安装即激活自动检测逻辑，不手动禁用会持续干扰 -
Code Runner：某些旧版本会在运行前强制重开文件，触发一次 auto-guess
排查方法：禁用所有插件 → 重启 VSCode → 检查右下角是否稳定显示 UTF-8 → 逐个启用插件观察变化。
插件开发中如何确保中文正确读取
如果你在写 VSCode 插件，需要读取用户文件内容（比如解析注释、提取字符串），别直接用 fs.readFile，那会绕过编辑器编码逻辑，大概率乱码。应统一使用：
vscode.workspace.openTextDocument(uri).then(doc => {
const text = doc.getText(); // 自动按 VSCode 当前解析规则返回 Unicode 字符串
});
关键点：
-
doc.getText()返回的是已解码的 JavaScript 字符串，不是原始字节，无需再做iconv-lite转换 - 若需获取原始字节（如做哈希、校验），用
doc.getData()，但它返回Uint8Array，编码含义由doc.uri对应的文件当前编码决定 - 不要在插件里硬写
"utf8"或"gbk"到fs.readFile的encoding参数，这和用户实际文件编码可能冲突
工作区插件配置 vs 用户级编码设置冲突
当项目根目录存在 .vscode/settings.json，且其中定义了 "files.encoding": "gbk"，那么即使你在 User 设置里写了 "files.encoding": "utf8"，对该工作区内的文件也无效——插件读取的仍是 GBK 解码结果。
这种场景下容易踩坑的地方：
- 插件功能测试时用的是全局 UTF-8 文件，上线后遇到老项目 GBK 文件，
doc.getText()返回乱码字符串 - 插件生成新文件时，
vscode.workspace.openTextDocument()创建的空白文档编码继承自工作区设置，不是 User 默认值 - 想让插件忽略工作区设置、强制用 UTF-8？做不到。VSCode 不提供 API 绕过 workspace-level encoding
唯一可控路径：在插件 UI 中提示用户检查当前文件编码（读 textDocument.languageId 和 textDocument.uri 后缀，结合 vscode.workspace.getConfiguration().get("files.encoding") 获取实际生效值），而不是假设它是 UTF-8。
