node.js调试cpu分析需用--inspect或--inspect-brk启动进程，配合vscode的launch.json配置type、request、port及runtimeargs，并在chrome devtools performance面板录制火焰图；插件滥用ipc或嵌套调用易致cpu飙升。
Node.js调试时怎么加--inspect参数启动CPU分析
VSCode本身不内置CPU火焰图，必须靠Node.js的V8 Inspector协议把运行时数据导出到Chrome DevTools。关键不是“在VSCode里点一下就分析”，而是让node进程带--inspect或--inspect-brk启动，否则DevTools连不上。
-
--inspect-brk适合分析启动阶段（比如服务初始化慢），它会停在第一行，等你点“继续”再执行，方便录制冷启动全过程 -
--inspect适合测用户交互逻辑（比如点击按钮后卡顿），不中断执行，你得手动在DevTools里点“Start profiling”再操作 - 如果项目用
nodemon，不能只写"runtimeArgs": ["--inspect"]——nodemon默认不透传参数，得改成"runtimeArgs": ["--exec", "node --inspect"]，否则端口监听失败
launch.json里必须配对的字段有哪些
光加runtimeArgs不够，type、request、port三个字段缺一不可，否则VSCode调试器压根不触发Inspector连接。
-
"type": "node"：固定值，不能写成javascript或js -
"request": "launch"：如果是attach模式（比如已运行的进程），要改成"request": "attach"并补"port": 9229 -
"port"建议显式指定，比如"port": 9229，避免多个调试会话端口冲突；默认是9229，但某些安全策略会拦截 - 别漏掉
"skipFiles"，加上["<node_internals>/**"]</node_internals>能过滤V8底层调用，让火焰图聚焦你的业务代码
Chrome DevTools里怎么正确录制和读取火焰图
点了“Open dedicated DevTools for Node.js”后，别直接进Console或Network——性能数据在Performance面板，但默认不显示JS堆分配和事件循环延迟，得手动勾选。
- 录制前先点右上角“⋯”→ More Tools → Rendering → 勾上“FPS meter”，能直观看到帧率跌穿30fps的位置
- 停止录制后，展开Bottom-up视图，按“Self Time”排序，找耗时最长的函数——注意区分是你的代码还是某个扩展的回调（比如
eslint.linter或prettier.format） - 如果火焰图里大量出现
process.nextTick或Promise.then堆积，大概率是异步任务没节流，比如文件监听器反复触发
为什么vscode-leetcode这类插件一开就CPU飙升
这类插件常把Node.js IPC当高频通道用，比如每秒发10+次process.send({ type: 'fetchProblem' })，而IPC序列化/反序列化本身就有开销，尤其传大对象时会拖垮Extension Host进程。
- 查
Developer: Open Process Explorer，如果Extension Host内存稳定在500MB+且CPU持续>60%，优先怀疑插件滥用IPC - 临时禁用插件后，在终端跑
code --status，对比“Renderer”和“Extension Host”的CPU占比变化 - 真要深挖，得用
node --inspect-brk启动VSCode自身（不是你的项目），然后在Chrome DevTools里录主进程——但这一步容易卡死，只建议确认是插件问题后再尝试
editor.formatOnSave触发Prettier，Prettier又调ESLint，ESLint再通过IPC查TS Server状态——三层嵌套下，单次保存可能引发400ms阻塞。定位时别只盯着最外层函数，得顺着火焰图往下调用栈钻。
