必须用 node --inspect 启动，因 vscode launch.json 的 pwa-node 模式延迟注入调试器，无法捕获 require 阶段的闭包、模块缓存等早期泄漏源；需终端执行 node --inspect=9229 启动，vscode 改为 attach 模式，并在 chrome://inspect 中通过三次堆快照对比、retained size 排序及 detached/closure 分析定位泄漏。
必须用 node --inspect 启动，不能靠 VSCode launch.json 直接运行
VSCode 自带的 launch.json 配置（"type": "pwa-node", "request": "launch"）会在 Node.js 进程启动后才注入调试器，此时 require 阶段创建的闭包、模块缓存、全局定时器等早期泄漏源早已分配完毕，根本捕获不到。你看到的堆快照，从第一帧起就“缺了一截”。
实操建议：
- 终端执行：
node --inspect=9229 --max-old-space-size=1024 app.js（加内存限制可加速 OOM 触发，缩短定位周期） -
launch.json改为attach模式，"port"必须与命令行一致（如9229） -
"localRoot"和"remoteRoot"都设为"${workspaceFolder}"，否则 Chrome DevTools 里看不到变量名，全是(compiled code)
Chrome DevTools Memory 面板才是唯一可靠入口
VSCode 内置调试器不支持堆快照对比、Retained Size 排序、Detached 对象筛选等功能。所有分析必须在 chrome://inspect 中完成。
关键步骤：
- 打开
chrome://inspect→ Configure → 添加localhost:9229→ 刷新 → 点击inspect - 切到
Memory标签 → 选Heap snapshot→ 连续拍 3 次：snapshot-0（空载）、snapshot-1（触发一次请求/操作）、snapshot-2（等待 30 秒后 GC 完成） - 右键
snapshot-2→Compare to previous snapshot→ 按Retained Size降序排列
重点盯死 Closure 和 Detached 类型对象
Node.js 里没有 DOM，但 Chrome DevTools 仍会把“长期存活却无引用路径”的对象标为 Detached——比如被 setInterval 箭头函数捕获的大 Buffer、未清理的 EventEmitter.on 监听器、模块顶层缓存的请求对象。
Rydberg Agent Node
下载
使用一条命令部署ProbeChain Rydberg测试网代理节点。自动注册为Agent(NodeType=1)，免gas，支持macOS/Linux/Windows。触发词：/r
快速定位泄漏根因：
- 展开
Closure构造函数 → 看Retainers面板 → 若出现cache、handlers、pendingRequests或大尺寸Array/Buffer，基本就是泄漏源头 - 筛选
Detached类型 → 点开看其Retained Size，若远高于同类对象（如 >5MB），说明它卡在 GC 路径外 - 典型陷阱：
server.on('request', handler)在循环中反复绑定却没调server.removeAllListeners()；或缓存 key 是临时Buffer且没设 TTL
别信插件“一键监控”，真实泄漏点都在 require 阶段
像 memwatch、heapdump 这类 npm 包，只能告诉你“有泄漏”，但无法指出泄漏对象在哪、谁在 hold 它、为什么没释放。它们对 require 阶段的模块缓存污染、global 上挂载的监听器、顶层 Map 缓存等场景完全无感。
真正要定位，必须满足两个硬条件：
- 进程由
--inspect启动，确保调试器从第一行 JS 执行前就在线 - 快照对比至少跨两次 GC 周期，否则
Retained Size波动全是噪声
漏掉任一条件，你看到的就只是表象——比如 process.memoryUsage().heapUsed 持续上涨，但快照里找不到大对象，那大概率是早期闭包链没被捕获。
