插件通知乱码主因是文件编码未被正确识别：右下角非utf-8时插件解析失败，应先reopen with encoding→utf-8验证，再save with encoding→utf-8 with bom固化；autoguessencoding对插件无效，终端乱码需单独配置chcp 65001及pythonioencoding。
插件通知乱码是因为文件编码未被正确识别
VSCode 插件（比如 ESLint、Prettier、GitLens）的错误提示、hover 提示、状态栏文字出现方块或问号，大概率不是插件本身的问题，而是插件读取的源文件用了非 UTF-8 编码（如 GBK），而插件内部默认按 UTF-8 解析字节流，导致解析失败。VSCode 编辑器界面能正常显示中文，不代表插件运行时也“看懂”了这些字节。
关键判断点：右下角状态栏显示的编码是否为 UTF-8？如果不是，插件几乎必然乱码——因为插件 API 拿到的是原始 buffer，不参与 VSCode 的编码重开逻辑。
- 点击右下角编码标识（如
GBK或ISO 8859-1），选Reopen with Encoding→UTF-8，观察插件提示是否立即恢复 - 若恢复，说明问题锁定在文件编码；若仍乱码，需继续排查插件自身或终端环境
- 注意：某些插件（如旧版
Auto Rename Tag）会直接读取未解码的文件内容，对files.autoGuessEncoding不敏感
settings.json 中 autoGuessEncoding 不保证插件生效
files.autoGuessEncoding 只影响 VSCode 自身的文件打开逻辑，不改变插件调用 vscode.workspace.openTextDocument() 时拿到的内容编码。插件拿到的 document 对象，其 getText() 返回值已按当前文档编码解码过，但前提是 VSCode 在加载时已正确识别编码。
也就是说：即使你设置了 "files.autoGuessEncoding": true，如果文件开头没有 BOM、又缺乏足够中文字符供启发式识别，VSCode 仍可能误判为 ISO-8859-1，插件随之拿到一堆乱码字符串。
- 强制让插件“看到”正确文本的最稳方式：保存文件为带 BOM 的
UTF-8（即utf8bom） - 在
settings.json中添加"files.encoding": "utf8bom"，新文件自动带 BOM，老文件需手动Save with Encoding→UTF-8 with BOM - 不推荐长期依赖
autoGuessEncoding处理中文项目，它在混合英文/数字/符号多的代码中极易失效
插件日志输出乱码要单独查终端编码链
部分插件（如调试器扩展、任务执行器）会在集成终端里打印诊断日志，此时乱码根源常在终端而非文件。即使文件是 UTF-8，终端仍可能用 chcp 936（GBK）运行，导致插件 console.log('中文') 被截断或替换为 。
验证方式：在终端里直接运行 echo "测试"，看是否乱码。若乱码，则插件日志必然乱码。
- 必须配置
terminal.integrated.profiles.windows，为 PowerShell/CMD 加上chcp 65001启动参数 - 额外加环境变量更保险：
"terminal.integrated.env.windows": {"PYTHONIOENCODING": "utf-8"}（针对 Python 插件） - Linux/macOS 用户需确认 shell 的
LANG是zh_CN.UTF-8，不是C或空值
第三方插件主动读文件时绕过 VSCode 编码层
像 Path Intellisense、TODO Tree 这类插件会自己调用 Node.js 的 fs.readFile() 读取文件，完全跳过 VSCode 的编码处理流程。它们默认用系统 locale 解码，Windows 上就是 GBK，导致路径、注释里的中文全变成乱码。
这类问题无法靠 VSCode 设置修复，必须从插件配置或系统级入手：
- 检查插件文档是否有
encoding配置项（例如todo-tree.general.encoding） - 若无，唯一可靠方案是：把整个工作区文件统一转为
UTF-8 without BOM，并禁用files.autoGuessEncoding避免干扰 - 极端情况可改系统区域设置——启用 Windows 的
Beta: Use Unicode UTF-8，让 Node.js 默认以 UTF-8 读文件
