应使用developer: open process explorer定位真实内存占用，重点查看extensionhost下带项目路径或插件名的子进程rss值，>500mb且不回落即存在泄漏；files.watcherexclude必须配为"/node_modules/": true等格式并重启工作区才生效。
怎么看哪个进程真在吃内存
VSCode 没有“当前工作区专属内存”这个数字，所有进程共享资源，但你可以通过 Developer: Open Process Explorer 定位和它强相关的部分：
- 打开命令面板（
Ctrl+Shift+P或Cmd+Shift+P），运行Developer: Open Process Explorer - 展开
extensionHost节点，找子项里带项目路径（如/home/user/my-project）或插件名 + 语言标识（如ms-python.python (python)）的进程 - 没显示路径的，右键 →
Reveal in Explorer看它加载的是哪个package.json或node_modules - 多根工作区下，每个根目录可能独立启动子进程；
Memory列数值高且路径匹配的，就是该根的主力消耗者
为什么 extensionHost 内存居高不下
extensionHost 是插件运行沙箱，也是内存泄漏重灾区。常见原因不是“插件多”，而是某些插件在后台持续驻留：
-
onStartup或onLanguage:*激活事件触发的插件（如ms-python.python、dbaeumer.vscode-eslint），一开编辑器就拉起完整服务，哪怕你没打开任何文件 - 插件注册了事件监听但没清理（比如
window.addEventListener('resize', ...)却没配removeEventListener） - 语言服务器（LSP）在大项目中构建全量符号表，AST 和类型信息长期驻留 V8 堆
- 某些插件瞬时占用高（如格式化一个 20MB JSON），但 30 秒后仍 >200 MB 就可疑
files.watcherExclude 配错等于没配
这是最常被写错、也最影响内存的配置。它不控制搜索或跳转，只管文件变更监听——而监听失控是内存缓慢爬升的主因：
- 必须写成
"**/node_modules/**": true，结尾的/**不能省；写成"**/node_modules"会漏掉子目录 - Linux 用户要检查
inotify句柄上限：cat /proc/sys/fs/inotify/max_user_watches，低于524288就需提升 - Windows 用户若仍卡顿，可额外执行
fsutil behavior set SymlinkEvaluation L2L:1 R2R:1（管理员权限），缓解符号链接扫描压力 - 配置改完必须关闭并重新打开工作区才生效；
Developer: Reload Window不触发重载监听器
别信 settings.json 里的“省内存”幻觉
很多教程推荐的优化项实际效果有限，甚至掩盖真问题：
-
files.watcherExclude和search.exclude只影响 watcher 进程，它通常只占 20–50 MB，不是内存大户 -
editor.largeFileOptimizations对单个大文件有效，但对整体内存压力影响微弱 - 真正有效的隐藏开关是：
extensions.autoCheckUpdates: false（实测降约 180 MB）、telemetry.telemetryLevel: "off"（降约 95 MB） - GPU 加速（
--enable-gpu）不是万能开关：M 系列 Mac 或独显本上开更顺；但 Intel Iris Xe 或老款 AMD GPU 下反而引发渲染线程阻塞和显存泄漏
内存波动本身正常，关键看趋势和上下文。空闲时 extensionHost 稳在 150–300 MB 属常见范围；持续 >500 MB 且不随关闭文件回落，基本可以断定是插件或 LSP 的泄漏——这时候堆快照比猜配置更有用。
