VSCode本身不检测性能，仅启动Node进程并暴露V8 Inspector接口；CPU分析必须由Chrome DevTools录制火焰图，漏配--inspect或launch.json中type、request、port任一字段均导致连接失败。
VSCode 本身不检测性能，它只负责把 Node.js 进程按需启动并暴露 V8 Inspector 接口；真正的 CPU 分析必须靠 Chrome DevTools 录制火焰图，漏掉 --inspect 或配错 launch.json 字段，就根本连不上。
怎么确认 Node.js 环境真能跑起来
别信插件图标或右键菜单——直接在 VSCode 集成终端里执行：node -v 和 npm -v。两者都返回版本号才算通过。
如果 node -v 成功但 npm -v 报错，大概率是 npm 被删了或权限异常，不是 VSCode 的问题。
更隐蔽的坑是：外部终端能跑 node，但 VSCode 终端里不行——这通常是因为 shell 配置（比如 ~/.zshrc）没被 GUI 启动的 VSCode 加载。此时运行 which node（macOS/Linux）或 where node（Windows），看路径是否一致。
launch.json 必须配对的三个字段
光加 runtimeArgs 不够，type、request、port 缺一不可：
• "type": "pwa-node"：新版推荐，旧版 "node" 类型不支持完整采样
• "request": "launch"：如果是 attach 已运行进程，得改成 "request": "attach" 并补上 "port": 9229
• "port": 9229：显式指定，避免多调试会话端口冲突；默认虽是 9229，但某些安全策略会拦截
漏掉任意一个，VSCode 调试器压根不会触发 Inspector 连接，Chrome DevTools 就连不上。
--inspect-brk 和 --inspect 到底用哪个
选错参数，录制时机就全错：
• --inspect-brk：进程启动后立刻停在第一行，适合分析服务初始化慢、依赖加载卡顿等“冷启动”问题
• --inspect：进程不中断，你得手动在 Chrome DevTools 的 Performance 面板点 “Start profiling”，再操作页面或调接口，适合测用户交互逻辑（比如点击按钮后卡顿）
如果项目用 nodemon，不能只写 "runtimeArgs": ["--inspect"]——它默认不透传参数，得改成："runtimeArgs": ["--exec", "node --inspect"]
否则端口监听失败，Debugger listening on ws://127.0.0.1:9229/ 这行日志根本不会出现。
Chrome DevTools 里怎么读火焰图才不被误导
点开 Open dedicated DevTools for Node.js 后，别急着点录制：
• 先点右上角 “⋯” → More Tools → Rendering → 勾上 “FPS meter”，能直观看到帧率跌穿 30fps 的位置
• 录制停止后，切到 Bottom-up 视图，按 “Self Time” 排序，找耗时最长的函数
• 注意区分：大量 process.nextTick 或 Promise.then 堆积，大概率是异步任务没节流（比如文件监听器反复触发）
• 如果火焰图里高频出现 eslint.linter 或 prettier.format，说明是插件在后台高频 IPC，不是你业务代码的问题
• 别忽略 "skipFiles": ["<node_internals>/**", "node_modules/**"]</node_internals>，否则底层调用占满视图，你的业务函数反而被淹没。
