很多 Node.js 问题表面上是“服务变慢了”，但真正的根因可能是阻塞调用、事件循环延迟、对象堆积或者垃圾回收压力。性能优化不是靠猜，而是靠理解运行时行为和证据分析。这一篇会把 Node.js 常见性能话题放到工程视角里理解。
为什么性能优化第一步不是改代码？
因为“慢”本身不是原因，而只是现象。你必须先知道到底是哪一类慢：
- 是 CPU 被打满；
- 是事件循环被阻塞；
- 是 I/O 等待太久；
- 是内存增长导致 GC 压力变大；
- 还是外部依赖不稳定。
如果这些没分清，就贸然优化，结果往往只是改了很多代码，却没有解决真正瓶颈。
阻塞点通常长什么样？
在 Node.js 里，典型阻塞点经常来自这些地方：
- 同步 I/O；
- 重 CPU 计算；
- 超大对象序列化与反序列化；
- 大量同步循环中的复杂逻辑。
它们的共同点是：会让主线程长时间占着不放，导致别的任务和回调都被延后处理。表面上看，你看到的是请求慢了；本质上，是事件循环被拖住了。
事件循环延迟为什么值得关注？
很多服务端问题并不是某个接口本身耗时特别长，而是整个运行时处理回调的节奏已经变慢。事件循环延迟可以帮助你判断：主线程是不是已经没法及时处理本该很快执行的任务了。
这类现象往往意味着：
- 当前线程负载过重；
- 某些同步逻辑占用时间过长；
- 或者系统整体已经处在比较紧绷的状态。
所以，对 Node 服务来说，观察事件循环延迟往往比只盯平均响应时间更有解释力。
堆内存和 GC 为什么要一起看？
只看内存占用有时是不够的。因为内存上涨可能有很多种含义：
- 正常缓存；
- 请求峰值导致的临时增长；
- 大对象暂时堆积；
- 或者真正的内存泄漏。
垃圾回收的表现能帮助你进一步理解这些变化。如果内存回收后一直降不下来，或者回收频率和停顿越来越明显，那通常说明问题已经不只是“用得多”，而可能是“留得太久”。
所以，堆内存和 GC 通常需要一起观察，而不是分开看。
更稳妥的性能排查路径是什么？
一个比较可靠的思路通常是：
1. 先确认问题是全局还是局部；2. 再确认更像 CPU、I/O、内存还是外部依赖；3. 再通过日志、指标、采样和局部实验收集证据；4. 最后才决定具体优化动作。
这套顺序的价值在于：先判断类别，再定位根因，最后才优化。否则你很容易在错误层面上越改越多。
总结
这一篇我们把 Node.js 性能与内存问题拉回到更真实的工程视角：阻塞点会拖慢主线程，事件循环延迟会暴露调度压力，堆内存和 GC 一起看才能更接近问题本质，而优化必须建立在证据之上。
下一篇会把工程实践阶段收束到 Node.js 的另一个强项，也就是 CLI 工具和 npm 包发布。