关于近期Node.js版本中async hooks（非存储API）的性能及生产实践问询

性能情况 #

• 近期Node.js版本（v16及以上，尤其是v18 LTS之后）对async hooks做了不少性能优化，相比早期版本（v10-v14）的开销已经大幅降低，但仍存在不可忽视的性能损耗，具体取决于业务场景。
• 官方文档标注的“可能影响性能”核心原因是：每个异步操作（包括Promise状态变更、异步函数调用等）都会触发before和after回调，高并发场景下回调的累积执行成本会被放大。
• 社区零散测试数据显示：在每秒处理数万次异步操作的重度Promise场景中，仅启用空的before/after回调，吞吐量可能下降10%-25%；如果回调中包含简单的上下文标记逻辑，损耗会在15%-30%左右；但如果回调有复杂计算或IO操作，损耗会飙升至50%以上甚至导致服务卡顿。
• 目前没有统一的生产环境基准测试报告，因为性能损耗和业务场景、回调逻辑复杂度强绑定，只能根据自身业务做针对性压测。

生产环境重度Promise场景的使用反馈 #

• 不少企业内部的APM链路追踪工具、异步上下文监控系统会基于这套API实现，在微服务调用、批量数据库查询（大量Promise链）的生产场景中广泛应用。
• 社区开发者反馈：在Node.js v18+的生产环境中，只要保证before/after回调是同步且轻量化的（比如仅传递上下文ID、做简单的日志标记），对服务整体性能的影响基本在可接受范围内（通常低于15%），不会成为性能瓶颈。
• 常见踩坑点：
  • 绝对不要在before/after回调中执行异步操作（比如发起HTTP请求、数据库查询），这会触发嵌套的async hooks回调，形成循环触发，最终导致性能雪崩甚至内存泄漏。
  • 在使用Promise.all、Promise.race这类批量操作时，每个子Promise的状态变更都会单独触发before/after，批量场景下的性能损耗会比单个Promise更明显，需要评估是否必须在这类场景下启用async hooks。
• 部分开发者会通过“按需启用”的方式降低损耗：比如仅在需要追踪的请求链路中启用async hooks，而非全局启用，以此平衡功能需求和性能开销。

内容的提问来源于stack exchange，提问作者Alexis Clarembeau