VSCode扩展冲突应通过分层管理与职责边界排查，遇启动失败报错时优先禁用EditorConfig/Prettier共存、ESLint/TSLint/Stylelint共存、多终端增强类及重复语法高亮扩展。
VSCode 扩展冲突和冗余不是靠“禁用一半再试”来排查的，而是靠分层管理 + 明确职责边界。
哪些扩展必须禁用才能确认是否冲突？
当你遇到以下现象时，Ctrl+Shift+P 输入 Developer: Toggle Developer Tools，切换到 Console 标签页，再复现问题（比如保存不格式化、右键菜单卡顿、自动补全失效），往往能看到类似 Extension 'esbenp.prettier-vscode' failed to activate. 或 Cannot find module 'vscode-languageclient' 的报错——这说明扩展启动失败或相互劫持了激活时机。
此时优先禁用以下几类扩展：
-
EditorConfig和Prettier同时启用且都设为默认格式化工具 -
ESLint、TSLint（已废弃）、Stylelint三者共存且都开启“保存时修复” - 多个终端增强类扩展，如
Terminal Tabs、Shell Launcher、Integrated Terminal Enhancer - 同语言的多套语法高亮/智能感知：比如同时装了
Python（官方）和Python Extension Pack（含重复子项）
如何用 workspace settings 精确控制扩展行为？
全局启用的扩展，在某个项目里可能完全不需要——比如你在纯前端项目里启用了 Go 或 Rust 扩展，它们虽不报错，但会占用内存并拖慢启动速度。更关键的是，某些扩展（如 GitLens）会在每个文件夹下扫描 Git 历史，导致大仓库打开极慢。
解决方式是：在项目根目录的 .vscode/settings.json 中显式关闭无关扩展：
仅从仓库的暂存文件生成 Git 提交消息。当用户要求 Codex 根据暂存更改、缓存差异、Git 索引或已通过 `git add` 添加的文件来编写、起草、创建或建议提交消息时使用；切勿代表用户执行提交操作。
{
"extensions.ignoreRecommendations": true,
"gitlens.enabled": false,
"editor.formatOnSave": true,
"[javascript]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
}
}
注意："esbenp.prettier-vscode" 是扩展 ID，不是显示名；ID 可在扩展详情页 URL 末尾或鼠标悬停“卸载”按钮时看到。
为什么重装 VSCode 后插件还在？
因为 VSCode 默认同步扩展（通过登录 GitHub 账号），即使你删了本地 .vscode/extensions 目录，下次启动仍会自动拉取上次同步的列表。这不是 bug，是设计行为。
若想彻底清空，需三步操作：
- 退出 VSCode
- 删除用户数据目录下的扩展缓存：
~/.vscode/extensions（macOS/Linux）或%USERPROFILE%\.vscode\extensions（Windows） - 在设置中关闭
sync.enable，或进入Settings Sync页面点击Turn Off（不是仅取消勾选“Extensions”）
否则，哪怕你手动删光扩展，重启后仍会恢复——同步服务只认账号状态，不校验本地是否存在。
真正难处理的从来不是“装多少”，而是“谁在什么时候接管了什么功能”。比如 TabNine 和 GitHub Copilot 都监听 editor.suggest，但前者默认禁用 TypeScript 补全，后者默认启用；这种细粒度覆盖，光看图标和开关根本发现不了。
