VS Code 突然变卡、风扇狂转、CPU 长时间高占用时，最常见原因通常不是编辑器本体，而是扩展插件冲突或插件行为异常。

这篇文章给你一套可以立即执行的排查路径，优先用最省时间的方法定位问题。

先做最快的定位：Start Extension Bisect

Start Extension Bisect 的核心思路是二分法： 每一轮临时禁用一半扩展并重启，通过你反馈“问题是否仍存在”，快速缩小范围，直到定位到可疑插件。

操作步骤：

1. 按 Ctrl+Shift+P（macOS 为 Cmd+Shift+P）打开命令面板。
2. 输入并执行 Start Extension Bisect。
3. 每次重启后观察 CPU 占用和卡顿是否复现。
4. 重复几轮后，VS Code 会给出可疑扩展列表。

定位后怎么处理

找到可疑插件后，建议按这个顺序处理：

1. 先更新插件到最新版本。
2. 若无改善，临时禁用该插件 1-2 天观察。
3. 对于功能可替代的插件，优先换成更轻量方案。
4. 若必须使用该插件，检查它的高级配置，关闭不必要的实时分析、索引或监听功能。

两个容易被忽略的“放大器”

即使主因是插件，以下配置也会放大 CPU 问题：

1. 搜索范围过大
   例如把构建产物、依赖目录、日志目录也纳入全局搜索，会让插件和文件索引持续高负载。

2. 文件监控包含大目录或软链接
   软链接、缓存目录、自动生成目录容易触发大量文件事件，导致扩展反复工作。

可以在 settings.json 中适当排除目录，例如：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

{
  "search.exclude": {
    "**/node_modules": true,
    "**/dist": true,
    "**/build": true
  },
  "files.watcherExclude": {
    "**/.git/objects/**": true,
    "**/node_modules/**": true,
    "**/dist/**": true
  }
}

复盘建议

如果你已经定位到问题插件，建议记录三件事：插件名称、触发场景、最终处理方式。
这样下次迁移环境或重装系统时，可以快速避开同类问题。

总结

VS Code 高 CPU 占用的排查，最有效路径是先用 Start Extension Bisect 快速定位，再结合搜索和文件监控范围做收敛。
先定位，再优化，比“盲目禁用一堆插件”更省时间，也更稳定。