VSCode调试器本身不提供独立性能检测功能，它仅转接Node.js等运行时的原生profiling能力；关键在launch.json中配置--inspect-brk启动参数，否则Chrome DevTools无法连接，CPU火焰图与内存快照均无法生成。
VSCode调试器本身不提供独立的性能检测功能，它只是把Node.js、Python等运行时的原生profiling能力“转接”给你——关键在配置和工具链衔接，而不是点开某个菜单。
launch.json里加--inspect-brk才是起点
没有这个参数，Chrome DevTools连不上你的Node.js进程，后续所有CPU火焰图、内存快照都无从谈起。
-
--inspect-brk会让进程启动即暂停，确保你有时间打开chrome://inspect并连接 - 如果用
nodemon，必须显式传参：nodemon --inspect-brk app.js，否则默认不启用调试协议 - 端口冲突常见于多人共用开发机或Docker环境，建议固定端口：
"runtimeArgs": ["--inspect-brk=9229"] - 别用
--inspect裸跑：它不暂停，容易错过首屏加载阶段的性能行为
chrome://inspect里Performance面板才是主力
VSCode界面里看不到火焰图，所有深度性能数据都在Chrome DevTools里生成和解读。
- 点击
chrome://inspect页面上的“inspect”链接后，进Performance标签页，点录制按钮（●）开始采样 - 操作你的应用（比如触发一次API调用、渲染一个列表），再点停止，你会看到完整的调用栈+耗时+主线程阻塞标记
- 重点关注
Self Time列高的函数——它们不是被谁调用得多，而是自己干得久 - 如果看到大量
GC Event或Layout抖动，说明是内存分配或DOM重排瓶颈，不是纯JS逻辑问题
console.time()适合快速验证，但别当真
它能帮你确认“这段代码是不是真慢”，但无法告诉你“为什么慢”或“慢在哪一层调用里”。
- 写法简单：
console.time('fetchData')→ 执行代码 →console.timeEnd('fetchData') - 输出精度是毫秒级，对IO类操作（如
fetch、fs.readFile）意义有限，因为网络/磁盘延迟掩盖了JS执行细节 - 多次调用同一名字会覆盖前一次计时，想测循环内单次耗时，得动态拼接label：
console.time(`item-${i}`) - 它不统计子函数调用，也不区分CPU忙还是等待I/O，仅作粗略锚点用
Developer: Open Process Explorer查的是VSCode自己，不是你的代码
这个命令常被误当成“查项目性能”，其实它只反映VSCode进程本身的资源占用，和你写的Node.js或Python程序完全无关。
- 重点看
Extension Host进程的Memory列：持续>300MB大概率是某个插件泄漏，比如ms-python.python加载大项目时没释放AST缓存 -
CPU列要看连续10秒是否>25%，单次峰值可能是格式化触发的瞬时计算，不具代表性 - 右键禁用扩展后，必须执行
Developer: Restart Extension Host才能真正释放内存，否则只是表面停用 - 如果你的编辑器卡，但这里一切正常，那问题100%出在你的代码逻辑或调试配置上，别在这儿浪费时间
真正容易被忽略的点是：VSCode调试器从不直接分析你的代码，它只负责转发V8或CPython暴露的profiling接口。一旦--inspect没生效、端口被占、或者Chrome DevTools没连对进程，你看到的就全是假数据——先验检查比反复录制更重要。
