必须用 node --inspect-brk=9229 app.js 启动 node.js 进程，再通过 chrome://inspect 连接并拍摄堆快照；仅靠 vscode 的 launch.json 默认配置无法启用 memory 面板，且需手动触发 gc、拍至少 3 个快照对比 retained size 和 detached 对象。
直接结论：VSCode 本身不泄漏，泄漏源几乎总在 extensionHost 进程或你调试的 Node.js 子进程里；必须用 --inspect 或 --inspect-brk 启动目标进程，再通过 Chrome DevTools 拍摄并对比堆快照，否则看到的只是“假高水位”。
怎么启动 Node.js 进程才能拍到有效堆快照
VSCode 的调试器（launch.json）默认连接的是 V8 Inspector 协议，但**不会自动暴露堆快照能力**，除非显式启用调试标志。常见错误是只配了 "type": "node" 却没传参数，导致 Chrome DevTools 连上后 Memory 面板灰掉。
- 正确做法：在
launch.json中加入"runtimeArgs": ["--inspect-brk=9229"]（加-brk可确保在第一行暂停，方便你先连 DevTools 再继续） - 或者终端手动启动：
node --inspect-brk=9229 app.js，再访问chrome://inspect→ Configure → 添加localhost:9229 - 别用
code --inspect-extensions去调试你自己的 Node.js 服务——那是给 VSCode 插件用的，端口冲突且目标进程不对 - 如果用
nodemon，需加--inspect到 exec 参数里：nodemon --exec node --inspect=9229 app.js
为什么拍了快照却找不到泄漏对象
堆快照不是“内存快照”，而是 V8 堆中**当前可达对象**的快照；若没触发 GC、或对象刚被创建还没被标记为“长期驻留”，它就可能淹没在噪声里。
使用一条命令部署ProbeChain Rydberg测试网代理节点。自动注册为Agent(NodeType=1)，免gas，支持macOS/Linux/Windows。触发词：/r
- 拍快照前务必手动触发 GC：在 DevTools Console 里执行
gc()（需开启--allow-natives-syntax）；更稳妥的是等自动 GC 发生后几秒再拍 - 至少拍 3 个快照：Baseline（空闲）→ 操作一次 → 操作两次，然后用 Comparison 模式逐对对比，重点看
Delta列为正且持续增长的Closure、Array、Object - 别只看
Size，要排序看Retained Size——真正吃内存的是它背后整条引用链，比如一个闭包持有了整个req对象，而req又引用了Buffer和headers - 筛选关键词：
Detached（DOM 节点泄漏）、Timeout（setInterval忘关）、EventEmitter（监听器堆积）
如何确认是 extensionHost 还是你的 Node.js 进程在泄漏
VSCode 有三个关键内存载体：渲染器（UI）、extensionHost（插件）、你跑的 Node.js（调试目标）。混淆它们会导致分析方向全错。
- 打开 VSCode 内置命令面板（
Ctrl+Shift+P），运行Developer: Open Process Explorer，观察各进程的Memory列：如果extensionHost持续上涨，问题在插件（如 Copilot、Jupyter）；如果process.12345（你的 Node.js PID）涨，才是你代码的问题 - 检查 DevTools 连接目标：在
chrome://inspect页面，“Remote Target” 下会明确列出VS Code Extension Host和Node.js app.js两类，点错就白忙 - 验证方式：临时禁用所有插件（
Ctrl+Shift+P→Extensions: Disable All Installed Extensions），再跑同样操作，若内存不再涨，就是插件泄漏 - 注意 WSL2 场景：若你在 WSL2 中用 Remote-WSL 打开项目，
extensionHost实际运行在 Linux 端，此时需在 WSL2 终端里执行ps aux | grep extensionHost查看真实内存占用
哪些泄漏模式最常被忽略
不是所有泄漏都表现为对象数量暴增；有些是单个对象 Retained Size 突破百 MB，但构造函数名很普通，容易被跳过。
-
Buffer泄漏：Node.js 中未销毁的fs.readFile回调、http.IncomingMessage流未.resume()或.destroy()，会导致原始字节一直挂在内存里 -
Closure捕获过大上下文：比如在on('data', () => { ... })回调里引用了外层整个class实例，而该实例持有数据库连接、缓存 Map、日志句柄等 -
Map/Set无限增长：没有 TTL、LRU 或clear()逻辑，尤其在中间件或请求生命周期中作为“临时缓存”使用 - WebAssembly 模块未释放：AI 插件（如 Copilot Chat）加载的
tokenizer.wasm实例，在扩展卸载后仍驻留于渲染器进程，需靠--inspect-renderer单独分析
最麻烦的不是发现不了泄漏，而是发现后无法定位到具体哪行 JS 代码——因为 V8 堆快照里的 Closure 名称常是 bound 或 <anonymous></anonymous>。这时候得回退一步：在疑似模块里加 console.log(new Error().stack)，或用 --trace-warnings 抓 MaxListenersExceededWarning，再顺藤摸瓜。
