核心是快速隔离、精准定位、按需优化：第一步用code --disable-extensions验证是否插件导致卡顿；第二步运行Developer: Show Running Extensions查看Startup Time超150ms或CPU/内存持续高占用的Running状态插件；第三步执行Developer: Start Extension Bisect二分法3–4轮锁定冲突源；第四步通过开发者工具Console和Extension Host日志查崩溃报错；第五步针对性调优配置而非卸载，如禁用GitLens缓存、限制ESLint检查时机、排除node_modules监视。
在 macos 上排查 vs code 插件冲突导致的卡顿，核心是快速隔离、精准定位、按需优化。不用猜，也不用全卸载，几步就能锁定问题插件。
第一步：用安全模式验证是不是插件惹的祸
关掉所有 VS Code 窗口，在终端执行：
code --disable-extensions
然后打开同一个项目，做你平时最卡的操作（比如打开大文件、保存、敲代码）。如果卡顿明显缓解或消失，基本可以确定是插件问题；如果还卡，就要查文件监视、语言服务或系统资源了。
注意：这个命令只是临时屏蔽，不改设置、不删插件，退出后一切照旧。
第二步：打开运行中的插件列表，看谁在拖主线程
按 Cmd+Shift+P 打开命令面板，输入并运行：
Developer: Show Running Extensions
重点关注两列：
- Startup Time：超过 150ms 的插件（如某些主题、Copilot、Remote-SSH）很可能在启动时就抢了主线程
- CPU / Memory：持续占用 >200MB 内存，或 CPU 波动频繁的（如 GitLens、ESLint、Prettier），往往是后台监听太激进
状态显示 “Running” 且 CPU 持续跳动的，才是真正在干活；“Activated” 却没耗时的，可能还没真正运行。
第三步：二分法精准揪出罪魁祸首
确认是插件问题后，别手动一个个禁用。直接运行：
Developer: Start Extension Bisect
VS Code 会自动把插件分成两组，轮流启用/禁用，每轮让你测试是否卡顿。通常 3–4 轮就能定位到那个一激活就让编辑器卡死或弹出 “Window is not responding” 的插件。
常见高危组合包括：
- ESLint + Prettier 同时设为默认格式器，
editor.formatOnSave开启后保存瞬间双重校验 - GitLens 在大型仓库中开启缓存和 CodeLens
- Remote-SSH 远程环境 Node.js 版本不匹配（比如本地 v18，远程 v16）
第四步：查崩溃日志，找隐藏报错
如果编辑器突然无响应或提示 “Extension host terminated unexpectedly”，按 Cmd+Shift+I 打开开发者工具：
- 切到 Console 标签页，扫三类关键错误：
•RangeError: Maximum call stack size exceeded（某插件递归监听整个node_modules）
•Cannot read property 'onDidChangeActiveTextEditor'（插件过早调用未就绪的 API）
• 反复出现的ERR! spawn ENOENT（插件调用了系统里没有的命令，比如python3） - 再切到 Output 面板 → 选择 Extension Host，往上翻，找到最后几条带
ERR!的日志，它前面紧挨着的Activating extension xxx就是崩溃源头
第五步：针对性优化，不一定要卸载
很多插件卡，不是功能重，而是默认行为太猛。比如：
-
GitLens：关掉
gitlens.codeLens.enabled和gitlens.advanced.caching.enabled -
ESLint：把
eslint.run改成onType或onSave，避免实时扫描整项目 -
AI 类插件（Copilot/Fitten Code/通义灵码）：只留一个，其余设为手动激活（如
"fitten-code.activationMode": "manual"），或关掉editor.suggestOnTriggerCharacters - 全局加
"files.watcherExclude": { "**/node_modules/**": true }，减轻文件监视压力
不复杂但容易忽略。
