vscode 不监控 node.js 进程真实资源占用，需用进程级工具；developer: open process explorer 仅显示 vscode 自身子进程，非用户 node 进程；chrome devtools 提供采样分析而非实时监控；pm2 插件可结构化展示真实 node 进程 cpu/内存；代码内主动打点最精准。
VSCode 本身不显示你 Node.js 进程的实时 CPU/内存占用，只监控编辑器自身；要看到 node app.js 真实的资源消耗，必须绕过 UI 层，用进程级手段对接。
Developer: Open Process Explorer 只看 VSCode 自己，不看你写的代码
这个命令（Ctrl+Shift+P → 输入 Developer: Open Process Explorer）列出的是 main、renderer、extensionHost 等 VSCode 子进程，不是你 node server.js 启动的服务进程。常见误判是把 extensionHost 的高内存当成你代码泄漏——其实那是 TypeScript 语言服务器在解析大项目。
- 它刷新单位是采样值，无时间轴，不能定位某次请求的峰值
- 右键可终止进程，但只是临时缓解，不解决你代码的问题
- 找不到你的
node进程 PID，就无法做后续监控
调试时用 Chrome DevTools 抓 CPU/堆快照，不是“实时监控”而是“采样分析”
VSCode 调试 Node.js 时启用 --inspect-brk，本质是让 V8 暴露调试端口，Chrome DevTools 才是真正的分析入口。这不是后台常驻监控，而是一次性录制。
- 在
launch.json中设"runtimeArgs": ["--inspect-brk"]，启动后点击状态栏的Open dedicated DevTools for Node.js - DevTools 的
Performance标签页点录制，操作完停止，能看 JS 堆分配、调用栈耗时、事件循环延迟 -
Memory标签页点Take Heap Snapshot，导出.heapsnapshot文件后必须用 Chrome 打开——VSCode 内置查看器只支持过滤，不支持火焰图下钻 - 别用
nodemon默认模式启动：必须加--inspect参数，且端口别被占（比如nodemon --inspect=9230 app.js）
用 PM2 插件在侧边栏看真实进程资源，但需本地运行 PM2
pm2-vscode 插件（作者 orchidfiles）能把 pm2 list 和 pm2 monit 的输出结构化展示在 VSCode 侧边栏，显示的是真实 node 进程的 RSS 内存和 CPU%，不是采样估算。
- 前提是你的项目已用
pm2 start app.js启动，插件会自动连接本地 PM2 守护进程 - 侧边栏直接点“重启”“日志”“查看内存趋势”，不用切终端
- 它不兼容 WSL 或远程容器里的 PM2：插件默认连
~/.pm2/rpc.sock，远程部署得配PM2_HOME和 socket 路径 - 内存数字来自
process.memoryUsage().rss，比top更准，但不包含 GC 暂挂对象
终端里用 psutil 或 process.memoryUsage() 主动上报，最稳
外部轮询（如 top -p $(pgrep -f app.js)）容易漏 PID 或受刷新间隔影响；在代码里主动打点，才是精准监控的起点。
- Node.js：在关键路径插入
console.log(process.memoryUsage())或用setInterval(() => console.error(JSON.stringify(process.memoryUsage())), 5000) - Python：装
psutil，写psutil.Process().memory_info().rss，比os.getpid()+ps更可靠 - 别依赖
Resource Monitor这类扩展：它查的是整个code进程组 RSS，数值虚高 20–30%，且无法区分 extensionHost 和你代码的内存归属 - 如果用 WSL，
ps命令行为和原生 Linux 不同，pgrep -f可能匹配不到，建议改用pidof node或记录启动时的$!
真正难的不是“怎么看到数字”，而是确认那个数字属于你正在调试的进程——PID 绑定错、端口冲突、调试模式选 launch 还是 attach，任何一个环节偏移，所有监控数据都失效。
