理解 Node.js 机制并不等于真的会排查 Node.js 问题。真正到项目里，更多时候你面对的是慢请求、内存涨高、日志断点、偶发错误和线上复现困难。这一篇会把调试与诊断能力作为运行时阶段的收束。
本地调试首先解决什么问题？
很多问题在代码层其实并不复杂，复杂的是你不知道它到底执行到了哪一步、当前变量是什么、哪一层先报错。这个时候，断点调试的价值就体现出来了。
Node.js 的本地调试能力，并不只是“能停一下”。它真正帮你解决的是：
- 调用链究竟怎么走；
- 某一步拿到的值到底是什么；
- 异步边界之间的状态如何传递；
- 错误真正从哪里冒出来。
所以，调试器的价值不是取代 console.log，而是让你在复杂流程里保留结构化观察能力。
日志为什么不是“多打几行字”？
很多团队早期遇到问题时，第一反应是多打日志，这当然没错。但如果日志没有结构、没有上下文、没有区分等级，最后很容易变成一堆噪音。
更成熟的日志思路通常会关心这些问题：
- 这是正常信息、警告还是错误；
- 当前请求或任务能否被追踪；
- 关键上下文是否被保留下来；
- 日志是否有助于复盘，而不是只是堆输出。
也就是说，日志真正的价值不在于“留下痕迹”，而在于“留下可用于判断的证据”。
性能问题到底该看什么？
很多 Node.js 性能问题表面看起来都像“服务变慢了”，但根因可能完全不同。你至少要先分清几类典型信号：
- CPU 占用是不是过高；
- 事件循环是不是被拖慢；
- 堆内存是不是持续上涨；
- 是 I/O 等待时间长，还是业务逻辑本身太重。
如果这些问题没分清，你就很容易把所有性能问题都归结成“Node 不行”或者“某个库太慢”，而真正的瓶颈可能根本不在那个层面。
所以，性能诊断的第一步不是优化，而是先识别问题属于哪一类。
线上问题为什么总比本地问题难？
因为线上问题很少会完整复现。你通常拿到的是某种现象，比如：
- 某个接口偶尔超时；
- 某台实例内存持续上涨；
- 某类请求在高峰期报错更多；
- 某个任务链路偶发失败。
这时最重要的不是立即猜结论，而是把范围尽快缩小。一个更稳妥的线上排障思路通常是：
1. 先确认问题是局部还是全局；2. 再确认是稳定复现还是偶发；3. 再判断它更像 CPU、I/O、配置、外部依赖还是数据问题；4. 最后才进入更细的日志、指标和样本分析。
也就是说，诊断的关键不只是工具，而是你有没有一条从现象走到证据的路径。
总结
这一篇把 Node.js 运行时阶段最后一块能力补上了：断点调试帮助你理解本地执行过程，日志帮助你保留诊断证据，性能分析帮助你看清瓶颈类别，而线上排障则要求你学会逐步收缩范围。
核心机制阶段到这里就差不多闭环了。接下来专题会进入工程实践，开始讨论依赖、脚本、项目结构和配置治理。