服务器内部的请求生命周期

当客户端向服务器发送 HTTP 请求时，系统不会立即执行业务逻辑。相反，请求会按照一系列定义好的步骤流转。这个流水线确保每个关注点——例如路由、认证和数据处理——都按正确的顺序处理。

典型的生命周期如下：

HTTP 请求
↓
路由器
↓
中间件
↓
认证
↓
业务逻辑
↓
数据库
↓
HTTP 响应

这种结构不是可选的——现代后端框架就是这样设计的。无论使用 Express、Django、Spring Boot 还是 FastAPI，所有系统都会实现这种流水线的某种变体。

它的好处是可控性和可预测性。不是把各种职责混在一起，而是让每一步都有清晰的目的。工程师可以在特定位置插入逻辑（例如在业务逻辑之前添加认证），而不会影响系统的其他部分。

如果没有这个流水线，后端系统很快就会变得混乱，验证、安全和业务逻辑会纠缠在一起。结构化的流程确保请求能够以一致、安全且高效的方式被处理。

当请求到达服务器时，第一个重要决定是：应该由哪段代码来处理它？这就是路由器的职责。

路由器会检查请求的两个关键部分：URL 路径和 HTTP 方法。它们组合起来，唯一地标识客户端想要做什么。

例如：

GET /users
→ usersController.getUsers

POST /orders
→ ordersController.createOrder

即使两个请求使用相同的 URL，不同的 HTTP 方法也可以把它们路由到完全不同的逻辑。这使 API 能够清晰地区分诸如读取数据（GET）和创建数据（POST）之类的操作。

在底层，框架会维护一个路由表，将请求模式映射到处理函数。当请求匹配某个路由时，就会执行对应的处理程序。

这种抽象让系统更有条理。开发者不需要手动编写条件逻辑去检查每个请求，而是以声明式的方式定义路由。框架会高效地完成匹配，确保每次都执行正确的代码。

中间件位于传入请求和处理该请求的最终处理器之间。请求不会直接从路由跳到业务逻辑，而是会经过一个或多个中间件函数。

流程如下：

请求
↓
中间件
↓
处理器

每个中间件函数都可以在请求到达下一步之前检查、修改，甚至停止该请求。这使得中间件在处理适用于多个路由的关注点时非常强大。

常见用途包括记录传入请求、验证身份验证令牌、检查请求数据、强制执行速率限制，以及以一致的方式处理错误。

中间件还可以将控制权传递给链中的下一个函数，从而形成分层处理模型。这样可以保持主要业务逻辑的整洁，因为重复性任务会被单独处理。

如果没有中间件，这些关注点就必须在每个处理器中重复编写，导致代码杂乱且难以维护。中间件将这些逻辑集中管理，并确保整个应用的一致性。

Authentication 会在系统执行任何业务逻辑之前验证请求者的身份。没有这一步，服务器会把每个请求都当作匿名请求，从而无法实施访问控制或用户特定行为。

这个过程通常通过 token、session 或 API key 来处理。例如，客户端可能会在请求头中发送一个 JWT，服务器对其进行验证；或者在 cookie 中包含一个 session ID，并将其映射到服务器上的用户记录。

一旦凭证被验证，系统就会提取诸如 user ID、roles 或 permissions 之类的身份信息。然后，这些信息会附加到请求上下文中，以便下游组件可以根据用户是谁来做出决策。

这一步被放在流水线的前面，因为系统的许多部分都依赖它。业务逻辑通常需要检查权限、获取用户特定数据，或根据身份实施限制。

如果 Authentication 失败，请求会立即被拒绝，通常返回 401 Unauthorized 响应。尽早处理可以防止未授权访问，并避免把资源浪费在不应该继续执行的请求上。

请求验证充当外部输入与内部逻辑之间的守门人。由于不能保证客户端会发送正确的数据，服务器必须对每个请求主动强制执行规则。

这些规则通常通过 schema 定义。schema 指定哪些字段是必需的、允许哪些数据类型，以及值应如何组织。如果请求不符合 schema，就会在进一步处理之前被拒绝。

例如，创建用户的请求可能需要一个格式有效的 email 字段。如果该字段缺失或格式错误，服务器会返回错误，而不是尝试处理无效数据。

除了结构验证之外，验证通常还包括清理输入。这样可以移除或转义危险输入，保护系统免受注入攻击或意外行为等问题的影响。

通过尽早强制执行验证，后端系统可以保持一致性、减少 bug，并防止无效数据进一步扩散到应用内部。

当请求通过路由、身份验证和验证之后，它就会到达控制器。控制器作为应用逻辑的入口点。它本身不包含复杂逻辑，而是负责协调接下来需要发生的事情。

控制器会调用业务逻辑，真正的工作就在这里发生。业务逻辑定义系统如何运行——如何处理数据、执行哪些规则，以及采取哪些操作。

例如，创建订单可能涉及多个步骤：计算总价、检查库存可用性，然后将订单保存到数据库。这些步骤属于业务逻辑，而不是控制器本身。

将控制器与业务逻辑分离，可以让系统保持简洁且易于维护。控制器处理请求流程，而业务逻辑专注于应用规则。这种分离使系统更容易测试、扩展和修改，同时不会破坏其他部分。

在业务逻辑确定需要发生什么之后，系统会与数据库交互以读取或写入数据。这就是管理持久化状态的地方——不同于内存中的数据，数据库中的数据会长期保存。

应用会向数据库发送查询，以检索信息或更新记录。这些查询可以从简单的查找扩展到涉及多个表或条件的更复杂操作。

在许多情况下，操作会被包装在事务中。事务可确保一组更改要么全部成功，要么全部一起失败。这对于保持一致性至关重要，尤其是在支付或订单处理等操作中。

一旦数据库处理完查询，就会将结果返回给应用。然后业务逻辑使用这些数据继续处理，或准备发送给客户端的最终响应。

在所有处理完成后，后端必须将内部结果转换为适合客户端使用的格式。这通常涉及将数据序列化为 JSON，以便通过 HTTP 传输。

服务器还会附加一个 HTTP 状态码来传达处理结果。这些状态码提供了即时上下文——请求是成功了、由于客户端输入而失败了，还是遇到了服务器端问题。

例如：

HTTP 200 正常
"userId": 42

这一步确保响应遵循一致的契约。客户端依赖可预测的格式和状态码来正确处理结果，而无需了解服务器内部实现。

一旦构建完成，响应就会通过网络返回。这标志着服务器对该请求的责任结束，完整的请求-响应循环也随之完成。