应使用Developer: Open Process Explorer查看extensionHost节点下各插件RSS内存占用，重点关注长期稳定>300MB的插件如eamodio.gitlens；禁用后需完全退出VSCode并检查进程是否清除，而非仅依赖启用状态列表。
怎么看哪个插件真在吃内存
别信“已启用”列表，很多插件注册了 onStartup 或 onLanguage:typescript 这类激活事件，一开编辑器就拉起独立进程，哪怕你没打开任何代码文件。直接看真实进程树才准：
- 按
Cmd+Shift+P（macOS）或Ctrl+Shift+P（Windows/Linux），输入并执行Developer: Open Process Explorer - 展开
extensionHost节点，右侧RSS列就是当前内存占用（单位 MB） - 点击列头排序，重点关注长期稳定在 >300MB 的插件，比如
eamodio.gitlens、dbaeumer.vscode-eslint、esbenp.prettier-vscode - 注意区分瞬时峰值和空闲驻留：关掉所有文件后 RSS 仍不回落，基本可判定泄漏
禁用插件后内存不降？根本没退出进程
点“Disable”只是标记状态，旧的 Extension Host 进程还在跑，引用未释放，内存纹丝不动。
- 右键插件 → 选
Disable (For All Folders)（不是只禁用当前工作区） - 必须完全退出 VSCode：macOS 要点菜单栏图标 →
Quit；Windows/Linux 要关掉所有窗口，任务栏托盘也要清空 - 重启后验证是否真退出：终端运行
ps aux | grep -i "pyright\|tsserver\|gitlens"，若无对应 PID 才算干净 - 临时验证可用
code --disable-extensions .启动，卡顿消失即锁定插件问题
GitLens / ESLint / Prettier 为什么特别容易爆内存
不是它们代码差，而是默认行为太“勤快”，在你不注意时疯狂分配对象、监听、缓存。
-
GitLens默认开启行级 blame 和历史图谱，gitlens.codeLens.enabled和gitlens.hovers.enabled两项一开，大文件下 DOM 节点暴增，内存直冲 500MB+ -
ESLint设为"eslint.run": "onSave"时，保存瞬间触发全文件解析，尤其带@typescript-eslint插件时，AST 构建吃光堆内存 -
Prettier在格式化大 JSON 或嵌套 JSX 时若未限制范围，会加载整棵树做 AST 遍历；旧版esbenp.prettier-vscode还存在未清除setTimeout的问题 - 这些插件多数运行在同一个
Extension Host进程里，一个泄漏，整个进程拖垮
files.watcherExclude 配错等于没配
这是最常被忽略、也最立竿见影的优化项。漏配或格式错误会导致内核级 inotify 句柄持续泄漏，内存爬升和插件无关。
- 必须写在项目根目录的
.vscode/settings.json中（不是用户级设置），否则不生效 - 通配符必须是
"**/node_modules/**": true，写成*/node_modules/*或node_modules都无效 - Linux 用户需检查
cat /proc/sys/fs/inotify/max_user_watches，低于524288就要调高，否则监听直接失败并退化为轮询 - Windows 用户若用 pnpm/yarn v3+，还需额外加
"**/.pnpm/**": true，否则 store 目录照样触发数万 inotify 句柄
真正难排查的是多个插件叠加泄漏 + watcher 配置失效的组合态——比如 GitLens 持续监听 node_modules（因 watcherExclude 没配对），同时 ESLint 在后台反复解析同一份 package.json，V8 堆里 Closure 对象就再也收不回来了。
