Node.js 性能分析（Profiling）实战指南
CPU 飙到 95% 却找不到元凶？本文实战四种 Profiling 工具：内置 --prof、Chrome DevTools、inspector 与 perf，并介绍持续性能分析的生产实践。
定位 CPU 热点的最快路径：node --cpu-prof app.js 生成 .cpuprofile 文件，Chrome DevTools 的 Performance 面板导入分析——火焰图直观显示每个函数的 CPU 占用。生产环境用持续 Profiling 方案替代手动抓包。
先分清：CPU 密集还是 IO 密集
CPU 飙高两种可能：真的在算（CPU-bound），或在疯狂上下文切换/GC。先确认用户态 CPU 占比——IO 密集的"高负载"是另一种病（连接耗尽、下游慢）。Profiling 解决的是前者。
内置 Profiler
node --cpu-prof app.js # 退出时生成 CPU 采样文件
# 或按需抓取
node --cpu-prof --cpu-prof-dir=/tmp/profiles app.js
Chrome DevTools 分析
打开 DevTools → Performance 面板 → 导入 .cpuprofile：
- 火焰图：横轴是时间占比，越宽的函数越耗 CPU——找"宽平顶"（自身耗时大的函数）；
- Heavy 视图：按自身耗时排序，直接列出最热的函数；
- 结合源码定位到行，优化目标一目了然。
Node Inspector 与 perf
- Inspector 实时抓：
--inspect+ DevTools 边跑边录——适合交互式复现的性能问题； - perf（Linux）：系统级采样（
perf record -F 99 -p <pid>）能看到 V8 之外（原生模块、系统调用）的开销——JS 层找不到答案时的终极武器。
持续 Profiling
手动 Profiling 的局限：问题在生产、复现靠运气。持续 Profiling（Continuous Profiling）在生产低开销常驻采样：随时回看任意时间段的火焰图，性能退化有据可查。这是现代可观测性的第三支柱（指标/日志/链路之外的 profile）。
把线上热点与请求表现对照
本地 CPU Profile 找到的热点，需要放回线上负载验证。观测云的 Node.js Profiling 文档给出了 Pyroscope 接入路径：应用引入 @pyroscope/nodejs，DataKit 单独开启 Profile 接收，再按服务、环境和版本查看采样结果。APM 与 Profiling 是不同数据通路，不能把仅接入 APM 描述为已经采集函数级 Profile；采样开销也应先在预发布环境测量。
接入文档：Node.js Profiling · Node.js APM 接入。
常见问题（FAQ）
Q：Profiling 对性能影响多大？
采样开销取决于负载、采样频率与分析选项；先在预发布环境比较吞吐、延迟与内存，再确定线上采集窗口。持续 Profiling 也需要单独配置与评估。
Q：火焰图看不懂怎么办？
抓三个要点：找最宽的"平顶"（自身耗时大）、区分 JS 帧与原生帧（GC 占比高是内存问题不是 CPU 算法问题）、对比正常时段的 Profile。
Q：异步代码的 CPU 时间怎么算？
事件循环回调的耗时分散在各 tick——火焰图按调用栈聚合依然有效，但"总等待时间"要用链路追踪（APM）视角看。
参考文档
本文依据公开文档整理，示例需按项目依赖版本验证；不将文档中的性能描述视为本项目实测结果。
