VSCode卡顿八成是插件抢资源，用Developer: Open Process Explorer查extensionHost的RSS内存、Developer: Show Running Extensions看Activation Time（超1000ms需警惕），并配置files.watcherExclude排除node_modules等目录。
大型项目卡顿，八成不是项目本身大，而是某个插件在后台疯抢资源——直接看 Developer: Open Process Explorer 和 Developer: Show Running Extensions 就能定位到真凶。
怎么看哪个插件正在吃内存
VSCode 任务管理器里看到的 “Code Helper” 内存值是假象，混着渲染进程、GPU 进程，根本分不清谁在拖慢你。真实内存占用得进 VSCode 自己的进程管理器：
- 按
Ctrl+Shift+P（Windows/Linux）或Cmd+Shift+P（macOS），输入并运行Developer: Open Process Explorer - 展开
extensionHost节点，每一行对应一个已启用插件，RSS列就是它当前占的物理内存（单位 MB） - 点击
Memory列标题排序，一眼揪出前几名：比如esbenp.prettier-vscode占 620MB、eamodio.gitlens占 480MB，基本就是它们 - 注意区分“瞬时峰值”和“空闲驻留”：格式化大 JSON 时
prettier-vscode飙到 500MB 属正常；但你关掉所有文件后它还稳在 350MB，大概率泄漏
为什么启动就卡？重点盯 Activation Time
很多插件不等你打开文件，一启动就开干，直接卡住主线程。别靠感觉猜，用内置命令看真实耗时：
- 运行
Developer: Show Running Extensions，重点关注Activation Time (ms)列 - 超过 1000ms 的插件高度可疑，尤其是
ms-vscode.js-debug、gitlens、ms-python.python这类默认声明"activationEvents": ["*"]或"onStartupFinished"的 - 状态长期显示
Activating或空白，说明它卡在初始化阶段，但还在后台占着线程、不报错也不退出 - 顺手在终端跑
code --status，输出里Extensions区域会标出每个插件的真实激活耗时，比 GUI 更准
files.watcherExclude 不配，插件再轻也白搭
VSCode 默认递归监听整个工作区，node_modules 几万小文件直接打爆系统 inotify 句柄——插件再怎么优化，事件风暴来了也扛不住：
- 必须在项目根目录的
.vscode/settings.json中加这段：
"files.watcherExclude": {
"**/node_modules/**": true,
"**/dist/**": true,
"**/build/**": true,
"**/.git/**": true,
"**/__pycache__/**": true
}
**/ 是关键，单星号 */ 或漏斜杠会导致子目录照样被扫描cat /proc/sys/fs/inotify/max_user_watches，若低于 524288，执行 echo 524288 | sudo tee /proc/sys/fs/inotify/max_user_watches
Reload Window 不生效禁用插件后内存不降？你可能没真正重启
右键插件选 Disable (For All Folders) 只是标记禁用，旧的 extensionHost 进程还在跑，内存纹丝不动：
- 禁用后，必须执行
Developer: Restart Extension Host（命令面板里搜），否则 RSS 值不会回收 - 更彻底的做法：关掉当前窗口，终端执行
code --disable-extensions重新打开同一项目；如果卡顿消失，100% 是插件问题 - 某些插件（如
Copilot、Remote-SSH）会注册全局监听器，即使禁用也可能残留子进程，此时需手动查ps aux | grep -i "copilot\|remote"并kill -9 [PID]
最麻烦的不是插件崩溃，而是它悄悄卡在激活阶段、不报错也不退出，让后续所有插件排队等它——这种问题光看控制台日志容易漏掉，必须靠 Developer: Show Running Extensions 和 Developer: Start Extension Bisect 双验证。
