VSCode本身不显示运行的Node.js进程PID，因其不托管终端启动的子进程；需用lsof、Get-NetTCPConnection或pgrep等系统命令查真实PID，code--status和任务管理器仅显示VSCode自身进程。
VSCode 本身不显示你运行的 Node.js 进程 PID，它只管调试协议和终端界面；真要查进程 ID，必须绕出去用系统命令——不是 VSCode 不行，是它压根不托管这些子进程。
为什么 code --status 或任务管理器里找不到你的 node 进程
VSCode 的进程树（比如通过 Developer: Open Process Explorer）只包含 Electron 主进程、渲染进程、插件宿主（extensionHost）等自身组件。你在集成终端里执行的 node app.js、npm run dev 或 pm2 start 启动的进程，是独立 fork 出来的系统级子进程，和 VSCode 没父子关系。
所以：
• 关掉 VSCode 窗口，node 进程可能还在跑（浏览器仍能访问 localhost:3000）
• code --status 输出里绝不会列出你的服务进程
• ps aux | grep node 查到的 PID，才是真实占用端口或消耗 CPU 的那个
在 VSCode 终端里快速定位当前任务的 PID
别指望终端标签页名（如 zsh 或 bash）告诉你正在跑什么。真正有效的线索藏在终端输出和 shell 环境里：
ZenHeart zenlink 与 zenlink-mcp 为 OpenClaw，涵盖安装、MCP 注册、钩子接线、入站轮询及升级维护。
- 如果刚启动了
node --inspect=9229 app.js，立刻在**同一终端**新开一行，运行：lsof -i :9229（macOS/Linux）或Get-NetTCPConnection -LocalPort 9229（PowerShell） - 如果服务监听
:3000，用：lsof -i :3000或netstat -ano | findstr :3000（Windows CMD） - 若
lsof报command not found（macOS），先brew install lsof；Windows 推荐直接用 PowerShell 命令，返回字段含OwningProcess，更干净 - 避免用
ps aux | grep app.js——容易匹配到日志或残留线程；改用pgrep -f "node.*app.js"（Linux/macOS）或tasklist /fi "imagename eq node.exe"（Windows）
launch.json 里 "request": "attach" 需要手动填 processId
VSCode 的 attach 模式不自动扫描进程，它只把配置里的 processId 值传给调试器（如 lldb）。你得自己先拿到 PID，再填进去：
- 启动服务时加
--inspect-brk参数（如node --inspect-brk app.js），然后用lsof -i :9229查 PID - 如果用了
nodemon，它会重启子进程，PID 变更频繁——建议改用nodemon --inspect app.js，再查新端口对应的 PID - PM2 用户可直接用
pm2 pid <app_name>获取 PID，比ps更准（前提是已用pm2 start启动） - 填进
launch.json时，确保"processId"是数字，不是字符串；且该 PID 当前必须存活，否则 attach 失败
别被 process.memoryUsage() 和 Debug Console 欺骗
在调试控制台里敲 process.memoryUsage() 只返回粗略统计值（heapUsed、external），既不能反映真实对象内存分布，也不能替代进程级 PID 查看：
-
heapUsed不含ArrayBuffer占用，大文件读取后内存飙升却看不到——它算在external里 - 没手动触发 GC（
global.gc()）就调用，堆里全是待回收对象，数值严重失真 - 想定位具体变量内存开销？必须用 Chrome DevTools 的 Memory 面板拍堆快照，VSCode 自带的“变量”面板只显示序列化结果
-
Developer: Open Process Explorer查的是 VSCode 插件内存（比如esbenp.prettier-vscode的 RSS），和你的node app.js完全无关
真正关键的永远是：先确认服务是否真在跑（curl localhost:3000 或 telnet localhost 3000），再用系统命令查 PID；VSCode 只负责连接和调试，不负责进程生命周期管理——这点容易被忽略，但恰恰是排查卡死、端口冲突、服务残留问题的起点。
