很多 Node.js 框架虽然语法不一样，但几乎都离不开“中间件”这个概念。真正理解中间件，不是会写一个打印日志的函数，而是理解请求从进入服务到返回响应，中间到底经历了哪些阶段。这一篇会把一次请求的生命周期完整串起来。
为什么中间件会成为核心扩展机制？
服务端请求链路里有很多能力并不属于某一个具体接口，而是很多请求都会经历的共性步骤，比如：
- 日志记录；
- 鉴权；
- 参数解析；
- 跨域处理；
- 异常包装；
- 响应统一。
如果这些逻辑全都写在每个接口处理函数里，项目很快就会重复、混乱且难维护。中间件的价值就在于：把这些横切关注点从业务逻辑里抽出来，放到统一链路上按顺序协作。
一次请求通常会经历哪些阶段？
虽然不同框架叫法不同，但一次请求的核心流程通常都差不多：
1. 请求进入服务；2. 基础解析和预处理；3. 日志、追踪、鉴权等横切逻辑介入；4. 进入真正的业务处理；5. 得到结果或错误；6. 响应被包装并返回。
这条链路之所以重要，是因为它告诉你：请求不是“直接进路由函数”，而是会经过一系列受控阶段。只有理解了这一点，你后面做结构设计时才知道哪些逻辑该放哪一层。
如果再细一点看，一条更完整的链路里往往还会出现这些时刻：
- 请求进入前的基础拦截，比如限流、黑名单或代理层处理；
- 进入应用后的上下文初始化，比如请求 ID、追踪信息、用户态；
- 路由命中前后的参数解析与校验；
- 业务执行后的结果包装、日志落点和异常统一转换。
这些阶段未必都用“中间件”三个字表达，有些框架会拆成钩子、插件、守卫、拦截器，但它们共同指向的仍然是同一件事：一次请求其实会经过很多受控关口。
横切关注点应该放在哪里？
中间件最适合承载的，通常是那些“很多请求都要经历，但又不属于单一业务逻辑”的事情。比如：
- 统一日志；
- 请求 ID 注入；
- 权限初筛；
- 通用异常处理；
- 基础限流或防护。
反过来，如果某段逻辑高度依赖具体业务规则，那么它更可能属于服务层，而不是应该被抽进中间件。
也就是说，中间件真正擅长的是共性能力，而不是替代业务编排。
判断一段逻辑该不该进中间件，一个很实用的问题是：如果把当前接口换成另一个业务接口，这段逻辑是不是大概率仍然成立？如果答案是“是”，它更可能属于横切能力；如果答案是“否”，它通常就更适合留在服务层或控制器层附近。
中间件最容易写乱在哪里？
最常见的问题通常不是“不会写”，而是：
- 责任边界越来越模糊；
- 某些中间件对顺序有强依赖却没人明确说明；
- 上下文里挂了过多隐式状态；
- 看起来都能工作，但谁先谁后完全靠经验记忆。
所以，随着项目变大，你不能只把中间件当作“方便插逻辑”的位置，而要开始把它当作正式请求链路的一部分去设计。
顺序问题尤其值得重视。比如鉴权依赖请求头解析，日志又希望拿到最终用户信息，异常处理中间件还可能需要知道上游是否已经写入响应。只要顺序靠“大家心里有数”，项目一大就很容易出现局部正确、整体混乱的情况。
请求上下文为什么既好用又危险？
很多 Node 框架都会提供某种请求上下文对象，让你可以在链路里共享信息。这非常方便，因为它能把请求 ID、用户信息、trace 数据、校验结果等内容沿着整条链路传下去。
但它的危险也在于：一旦什么都往上下文里挂，很多依赖关系就会变成隐式的。代码表面上看起来很简洁，实际上却越来越难判断“这个字段到底是谁写进去的”“在哪个阶段一定可用”。当这种隐式状态变多以后，调试和排障成本会明显上升。
所以，更健康的做法通常是：
- 只把确实需要跨层共享的信息放进上下文；
- 明确哪些字段由哪个阶段注入；
- 避免把业务结果、临时状态、数据库实体全都塞进去。
理解生命周期，对后面的架构设计有什么帮助？
一旦你建立了请求生命周期视角，很多结构判断就会变得更清楚。比如：
- 校验应该尽量发生在业务逻辑之前；
- 通用异常最好在统一边界收口；
- 日志既要有入口记录，也要有结果落点；
- 业务核心逻辑不应该依赖太多中间件副作用。
换句话说，请求生命周期并不只是一个“框架原理题”，它其实是后面分层、调试、监控和性能优化的基础地图。
总结
这一篇我们把服务端请求生命周期先拉清楚了：中间件之所以重要，是因为它把横切关注点从业务代码中分离出来，让一次请求沿着受控链路逐步推进。
下一篇我们会继续顺着这条链路往下走，讨论一个 Node API 项目在结构上应该如何拆层。