禁用插件是提升vscode多工程并行处理能力最直接有效的手段；gitlens、eslint、prettier、ms-python.python和ms-vscode.cpptools在多工程场景下最易冲突，需通过disable (workspace)禁用并彻底关窗重开验证生效。
禁用插件是提升 VSCode 多工程并行处理能力最直接有效的手段，80% 以上的卡顿和 CPU 冲突根源就在这里——不是插件功能不好，而是它们在多个工作区同时加载、监听、响应时互相抢资源。
哪些插件在多工程场景下最容易“打架”
当你同时打开多个文件夹（比如前端项目 + 后端服务 + 工具脚本），VSCode 默认会为每个工作区加载所有已启用插件。但很多插件根本没做工作区隔离，一开就全局驻留：
-
GitLens：默认监听整个文件系统 Git 状态，多个项目同时刷新时 CPU 持续飙高 -
ESLint：若配置了eslint.workingDirectories或启用全项目扫描，多个工程会各自启动语言服务器，内存叠加爆炸 -
Prettier：尤其当.prettierignore缺失或路径匹配宽泛时，它会在每个 .js/.json/.md 文件保存时触发格式化，串行阻塞事件循环 -
ms-python.python和ms-vscode.cpptools：即使只在一个工作区用 Python/C++，它们也会在后台预占 LSP 进程，导致其他工作区的 JS/TS 补全变慢
禁用必须分清作用域：Workspace 级才是多工程解法
全局禁用插件看似省事，实则破坏开发流——你不能为了跑 Node 项目就关掉 Python 插件，否则切到 Django 仓库就彻底没智能提示。真正该做的是按需隔离：
- 右键扩展 → 选
Disable (Workspace)：仅对当前文件夹生效，图标旁出现灰色Workspace标识 - 别点错成
Disable (For All Folders)：那是全局禁用，会同步到用户级settings.json - 禁用后必须彻底关窗重开：VSCode 的 Extension Host 进程不会因禁用自动卸载，
Developer: Reload Window不够，得退出整个窗口（macOS 还要退出菜单栏图标） - 验证是否真生效：终端执行
code --status记下 Extension Host PID，关窗重开后再ps -p [pid] -o args=，确认目标插件路径已消失
工作区配置 extensions.disabled 怎么写才不踩坑
手动点禁用容易漏，且无法版本控制；写 .vscode/settings.json 是团队协作和多工程复用的关键，但 ID 必须精确：
- ID 必须是市场页 URL 最后一段，比如
esbenp.prettier-vscode，写成prettier或prettier-vscode都静默失效 - 数组写法：
"extensions.disabled": ["esbenp.prettier-vscode", "eamodio.gitlens"] - 别和
extensions.enabled混用：后者是白名单模式，一旦漏写某个必需插件，整个工作区语言支持就崩 - Vue/React 项目慎禁
prettier-vscode：Volar 或 Vetur 可能依赖其底层 API；建议改用语言级开关："[vue]": { "editor.formatOnSave": false }
排查多工程冲突的终极干净起点
当你不确定哪个插件在多个工作区间捣乱，唯一 100% 可靠的方式是跳过所有插件加载流程：
- 终端执行：
code --disable-extensions /path/to/project-a（注意：参数必须放在命令末尾） - Windows 用户别右键图标“以管理员身份运行”再拖文件——GUI 启动绕过命令行参数，插件照常加载
- macOS 正确姿势：
open -n -b "com.microsoft.VSCode" --args --disable-extensions /path/to/project-b - 禁用后如果响应明显变快，说明问题确实在扩展层；再逐个启用插件定位元凶，而不是靠猜
多工程并行时最易被忽略的一点：插件激活不是“按工作区注册”，而是“按 activationEvent 响应”。一个 onLanguage:json 的插件，只要任意工作区打开一个 .json 文件，它就在整个 VSCode 实例里常驻——所以禁用动作本身不等于卸载，关窗重开这一步绕不开。
