VSCode内存卡顿主因是插件RSS驻留过高，应通过Developer: Open Process Explorer定位extensionHost下空闲时仍>300MB的插件（如Prettier、GitLens），禁用后须重启Extension Host或用code --disable-extensions验证，并调整其默认激进配置。
VSCode 本身不显示“编辑器内存使用详情”这种聚合数值，它只暴露进程级 RSS 内存（单位 MB），而真实瓶颈几乎总在 extensionHost 进程里——直接看 Developer: Open Process Explorer 就够了，别被任务管理器里的 “Code Helper” 数值误导。
怎么看 extensionHost 进程的真实内存占用
系统任务管理器或活动监视器看到的 “Code Helper” 或 “Visual Studio Code” 主进程内存，是多个子进程 RSS 的模糊叠加，无法定位具体插件。VSCode 自己的进程树才反映真实分配：
- 按
Ctrl+Shift+P（Windows/Linux）或Cmd+Shift+P（macOS），输入并运行Developer: Open Process Explorer - 展开
extensionHost节点，下面每一行就是一个已启用插件，旁侧数字即当前 RSS 内存（MB） - 点击
Memory列标题排序，重点关注空闲状态下仍稳定 >300MB 的条目（比如esbenp.prettier-vscode或eamodio.gitlens） - 注意区分瞬时峰值（如格式化大 JSON 后飙到 600MB）和驻留占用（关掉所有文件后仍卡在 420MB）——后者才是泄漏信号
禁用插件后内存不降？必须重启 extensionHost
右键插件选 Disable (For All Folders) 只是标记状态，旧进程仍在运行，内存不会释放：
- 禁用可疑插件后，立刻在命令面板运行
Developer: Restart Extension Host - 观察
Process Explorer中extensionHost子项是否刷新、RSS 是否回落 - 若仍无效，关闭当前窗口，终端执行
code --disable-extensions /path/to/project重新打开——如果卡顿消失，100% 是插件问题 - 某些插件（如
GitHub.copilot、ms-vscode-remote.remote-ssh）会注册全局监听器，禁用后可能残留子进程，需手动ps aux | grep -i "copilot\|remote"+kill -9 [PID]
哪些插件配置容易触发内存暴涨
不是插件代码有 bug，而是默认行为太激进，在大型项目中迅速失控：
-
gitlens.advanced.caching.enabled设为true：全仓库符号缓存常吃掉 200–300MB，关掉立竿见影 -
eslint.run设为onType：每敲一个字符就跑一次 AST 解析，改成onSave可大幅缓解 -
prettier.requireConfig为true但项目根目录无.prettierrc：插件会遍历整个工作区找配置，尤其在含node_modules的项目里极易失控 -
emeraldwalk.runonsave类自动执行插件，若命令含find . -name "*.js" | xargs grep -l "TODO"这种递归扫描，在大仓库中会持续占满 CPU 并堆积内存
别试图查单个 JS 变量内存大小
VSCode 调试器不提供变量字节数，JSON.stringify(obj).length 或 typeof 完全失真——JS 对象内存取决于引用图、闭包、原型链和底层 V8 结构（如 Map 哈希表扩容、字符串 SlicedString 共享）：
- 真要定位大对象，用
Developer: Open Web Inspector→Memory→Take heap snapshot，拍 2–3 个快照对比Retained Size - 重点看
Retainers树顶部：谁持有该对象？比如某个插件的cacheMap或未移除的eventListener - 留意
Detached DOM tree类型——说明插件创建了 DOM 但没清理，长期泄漏 - 日常排查优先级永远是：先
Process Explorer锁定高 RSS 插件，再深入堆快照；90% 的“卡顿”根本不用碰调试器
真正卡住 VSCode 的，从来不是你写的某行代码，而是某个插件在你不注意时悄悄建了个 50MB 的缓存 Map 并忘了删——盯紧 Process Explorer 的 Memory 列，比调任何调试器都管用。
