VSCode无真正“一键分析性能瓶颈”功能，其所谓Node.js性能分析插件仅调度node --inspect/--prof并跳转Chrome DevTools；需通过Process Explorer排查插件自身开销，正确配置launch.json三字段（type、request、port），并在DevTools Performance中勾选关键指标交叉验证。
VSCode里没有“一键分析性能瓶颈”的插件
别被名字带偏——所谓“Node.js性能分析插件”，本质是帮你启动node --inspect或node --prof，再把日志导出或跳转到Chrome DevTools。VSCode本身不内置火焰图渲染器，也不做采样计算，它只是调度器和管道。
你装的vscode-leetcode、Code Runner甚至Thunder Client，都可能在后台高频调用IPC或监听文件，反而掩盖真实瓶颈。真要定位CPU热点，得先确认问题不在插件自己身上。
- 打开命令面板（
Ctrl+Shift+P），运行Developer: Open Process Explorer，看Extension Host进程是否长期占CPU >30% - 临时禁用所有非官方扩展：
code --disable-extensions启动VSCode，再测一次基准 - 如果禁用后火焰图变干净，就逐个启用，重点盯
process.send调用频繁的插件（比如自动格式化、实时预览类）
launch.json必须配对的三个字段：type、request、port
只加"runtimeArgs": ["--inspect-brk"]没用。VSCode调试器根本不会尝试连接V8 Inspector，除非这三个字段同时存在且合法：
-
"type": "node"：不能写成"javascript"或漏掉引号 -
"request": "launch"：如果是attach已运行进程，得改成"request": "attach"并补"port": 9229 -
"port": 9229：显式指定，避免被其他调试会话或安全策略拦截；默认虽是9229，但某些Linux发行版会限制低端口
漏掉任一字段，VSCode连调试按钮都不亮，更别说触发--inspect参数。
Chrome DevTools Performance面板里真正要看的三项
点开chrome://inspect → Open dedicated DevTools for Node.js → 进Performance面板，别只盯着“主线程”那一栏。关键数据藏在设置里：
用于端到端视频本地化流程的轻量编排器，路由至四个专注子技能——/wjs-transcribing-audio、/wjs-translating-subtitles...
- 录制前手动勾选：
JS heap allocation（看内存分配热点）、Event loop lag（识别I/O阻塞）、Network（确认不是HTTP请求拖慢） - 停止录制后，切到
Bottom-up视图，按Self Time排序——排第一的函数名如果是process.nextTick或Promise.then，说明异步任务没节流，不是你的业务代码慢，是调度逻辑失控 - 展开调用栈时注意路径：
your-module/index.js:123才是你要改的；<node_internals>/internal/.../fs.js说明瓶颈在底层IO，得换stream或加缓存
nodemon透传--inspect参数的唯一可靠写法
用nodemon时，直接写"runtimeArgs": ["--inspect"]一定失败。因为nodemon默认不把参数透传给子进程，它只监听文件变化并重启node，但没把--inspect带上。
正确写法只有这一种：
"runtimeArgs": ["--exec", "node --inspect-brk"]
注意两点：
- 必须用
--exec，告诉nodemon“接下来的字符串是完整执行命令” -
--inspect-brk比--inspect更稳妥：服务启动卡在初始化阶段时，你能确保DevTools连上后再点“继续”，录到冷启动全过程
如果项目还用了ts-node或tsx，就得把node换成对应二进制名，比如"--exec", "tsx --inspect-brk"，否则端口监听失败。
真正难的不是启动分析，而是从火焰图里区分“你的代码耗时”和“框架/插件/工具链的开销”。尤其当多个setTimeout嵌套、IPC消息堆积、或require路径过深时，V8采样容易失真。这时候得交叉验证：node --prof生成的日志 + node --prof-process解析结果，比DevTools单次录制更可信。
