vscode需通过--inspect启动node.js进程并连接chrome devtools才能获取真实性能数据；launch.json必须配置runtimeargs启用v8 inspector，否则监控为静态假数据。
VSCode 本身不采集 Node.js 运行时性能数据，必须通过 --inspect 启动进程并连接 Chrome DevTools 才能拿到真实、可交互的 CPU/内存分析结果——插件界面再漂亮，底层没连上 V8 Inspector，监控就是静态假数据。
launch.json 必须加 --inspect 参数才能启用分析能力
VSCode 的 JavaScript Debugger 只负责“转发”调试协议，不自带采样引擎。没这个参数，Chrome 就连不上，Performance 面板一片灰。
-
"runtimeArgs": ["--inspect-brk"]：启动即暂停，适合在第一行设断点后再开始录制 -
"runtimeArgs": ["--inspect=9229"]：指定端口，避免与已有 Node 进程冲突（比如 PM2） - 别用
--inspect-brk+ 自动执行脚本的组合，否则可能因断点卡死导致无法触发录制 - 如果项目用
npm start，需改用"runtimeExecutable": "npm"并设"args": ["start"]，否则runtimeArgs不生效
Chrome DevTools 是唯一可靠的数据入口
VSCode 内置的 “Developer: Open Process Explorer” 只能看扩展进程，对你的 Node.js 应用无效；所谓“CPU Profile”按钮实际也是跳转到 Chrome 的 chrome://inspect。
- 启动调试后，在 VSCode 状态栏找 WebSocket 地址（形如
ws://127.0.0.1:9229/...），复制进 Chrome 的chrome://inspect页面 - 点 “Configure” 添加
127.0.0.1:9229，确保目标自动出现 - 在 Performance 标签页点击录制，操作几秒后停止 → 查看主线程堆栈、事件循环延迟、GC 频次
- Memory 标签页点 “Take Heap Snapshot”，导出
.heapsnapshot文件后，必须用 Chrome 打开才能做对比或对象筛选
Watch 表达式可实时盯住关键指标，但有作用域限制
Debug Console 和 Watch 面板不是万能仪表盘，它们只反映当前暂停帧的上下文，变量一出作用域就失效。
- 在 Express 路由 handler 里加断点，Watch 输入
process.memoryUsage().heapUsed，能看到每次请求前后内存变化 -
global.gc()在 Debug Console 中可手动触发 GC（需启动时加--expose-gc参数） - Watch 表达式不能跨异步边界：比如在
setTimeout回调外设断点，setTimeout内部变量不会出现在 Watch 列表里 - 避免写
require('fs').readFileSync(...)这类副作用表达式进 Watch，会重复读文件甚至阻塞线程
远程/WSL/容器环境要手动暴露调试端口
本地开发跑得通，不代表 WSL 或 Docker 里也能连上 —— --inspect 默认只监听 127.0.0.1，而 WSL 的 localhost 和 Windows 不是同一个网络栈。
- WSL：改用
--inspect=0.0.0.0:9229，并在 Windows 防火墙放行该端口 - Docker：启动容器时加
-p 9229:9229，且launch.json中"port"设为9229，"address"设为"0.0.0.0" - Live Share 无法共享 profiling 数据：所有快照和时间线都只存在发起方机器上，协作时对方看不到你的 CPU 录制结果
- 别信“一键分析”类插件的图标按钮——它们只是包装了
chrome://inspect的跳转逻辑，没做任何额外采样
真正容易被忽略的是：V8 的 CPU Profiler 默认只采样主线程，Worker Thread 或 child_process 的负载完全不会出现在主火焰图里；想看完整视图，得单独 attach 到子进程，或者改用 node --prof + node --prof-process 解析日志。这一步没人提醒，但线上问题往往就藏在 Worker 里。
