VSCode本身不生成CPU火焰图，需通过launch.json配置--inspect启动Node进程，再用Chrome DevTools Performance面板录制并导出分析；火焰图横向长度代表函数总耗时（含子调用），最宽横条即优化入口，红色仅为默认配色。
Node.js服务在VSCode里怎么抓CPU火焰图
VSCode本身不生成火焰图，但能启动带--inspect的Node进程，让Chrome DevTools接管采样。关键不是“在VSCode里点一下就出图”，而是让VSCode成为调试入口，把性能数据导出给真正能画图的工具。
- 确保
launch.json里启用--inspect（别用--inspect-brk，它会卡住采样起点） - 启动调试后，VSCode底部状态栏出现“Open dedicated DevTools for Node.js”链接，点击跳转到
chrome://inspect - 在DevTools的
Performance面板点录制，操作你的服务（比如发几个HTTP请求），停止后点击Reload with profiling可补全符号信息 - 导出的
.json文件必须用Chrome DevTools打开——VSCode内置的“性能提示”只显示调用栈深度，不提供火焰图
为什么火焰图里看不到你写的函数
常见原因是V8符号未正确解析，尤其在生产构建或打包后。火焰图显示一堆[Unknown] [SharedStubs]或[C++]，说明采样数据没映射回源码。
- 开发阶段：确保Node启动时加
--no-snapshot和--interpreted-frames-native-stack，避免V8跳过JS帧 - 使用
source-map-support包，并确认launch.json中sourceMaps设为true，否则断点能打、火焰图却对不上行号 - 若用Webpack/TSC编译，检查
devtool: 'source-map'是否生效，且outDir路径与sourceMapPathOverrides匹配 - 别依赖
node --prof输出的isolate-*.log直接生成火焰图——它需要额外用node --prof-process处理，且不支持Source Map
火焰图里红色区块到底代表什么
横向长度是函数总耗时（含子调用），不是纯执行时间；纵向是调用栈深度。所谓“红色”只是默认配色，实际要看宽度——最宽的那条横条，才是你该优化的入口函数。
Comprehensive Three.js 3D graphics reference
下载
详细的 Three.js 3D 图形参考，涵盖场景设置、相机、几何体、材质、光照、动画、控制器、加载器、数学工具和调试。
- 如果
app.listen()很宽，说明问题不在业务逻辑，而在启动阶段（比如同步读大配置、未延迟初始化的中间件） - 看到大量
Promise.then或nextTick堆叠，往往意味着微任务队列被长链阻塞，需检查await缺失或Promise.all误用 -
[C++]占比高（>30%），说明瓶颈在原生模块（如bcrypt、sqlite3），JS层再优化也没用，得换算法或异步封装 - 火焰图顶部窄、底部越来越宽，是典型的“扇出”问题——一个函数并发调用N个慢IO，应考虑限流或降级
vscode-js-debug的CPU分析和Chrome DevTools的区别
vscode-js-debug内置的“开始性能分析”按钮确实能弹出火焰图，但它只采集JS执行帧，且不支持Source Map回溯，本质上是简化版V8采样器。真实项目里，它常漏掉关键路径。
- 它无法捕获
fs.readFileSync这类同步阻塞调用的真实耗时，只显示JS层等待时间 - 对Worker线程、Child Process、WebAssembly模块完全不可见，而Chrome DevTools的
Performance面板能跨上下文追踪 - 如果你在
launch.json里配了env变量（比如NODE_OPTIONS=--max-old-space-size=4096），vscode-js-debug的分析会受其影响，但DevTools不受干扰 - 真正要定位I/O瓶颈，必须结合
Network面板看请求排队、Memory面板看堆增长，单靠火焰图会误判
火焰图不是终点，而是缩小范围的起点。真正卡顿的地方，往往藏在异步链深处、第三方库回调里，或者被await掩盖的I/O延迟——这些不会自动高亮，得靠反复缩小分析范围，再配合日志和网络面板交叉验证。
