FastAPI中间件实战：从重复代码到统一管控的架构优化-代码聚汇网

FastAPI中间件实战：从重复代码到统一管控的架构优化

社长从来不假装·2026-08-31·阅读 23 GEO检测（免费）

FastAPI中间件BaseHTTPMiddleware

|难度：普通|阅读约 45 分钟

前阵子我重构班级管理系统的后端，把散落在几十个接口里的登录校验、权限判断、异常捕获、日志记录全删了，改成一层层中间件统一管控。删完之后工程清爽得不像话，新增接口的时候只需要写业务代码，其他横切逻辑一概不用管。今天就把这次从“重复造轮子”到“统一管控”的完整过程拆开来聊聊，内容包括中间件原理、实战代码、踩坑记录和架构取舍，适合正在用 FastAPI 写后端、又苦于重复代码太多的同学参考。

1. 项目背景：为什么我会走上“重复造轮子”这条路

1.1 最初的代码写成了什么样

班级管理系统早期功能简单，后端就几个模块：学生管理、教师管理、课程安排、成绩录入、公告发布。刚开始接口少，我习惯在每个路由函数里直接写校验逻辑。就拿“获取学生列表”这个接口来说，几十行代码里有大半跟业务无关：

python复制@router.get("/students")
async def list_students(request: Request):
    token = request.headers.get("Authorization")
    if not token:
        return {"code": 401, "msg": "未登录"}
    user = verify_token(token)
    if not user:
        return {"code": 401, "msg": "登录已过期"}
    if user.role != "admin":
        return {"code": 403, "msg": "无权限访问"}
    try:
        students = await get_students_from_db()
        return {"code": 0, "msg": "ok", "data": students}
    except Exception as e:
        logger.error(f"查询学生列表失败: {e}")
        return {"code": 500, "msg": "服务器内部错误"}

这个写法在接口少的时候没什么问题。但班级管理系统功能越加越多，考勤、选课、成绩分析、家长通知，接口数量很快突破三十个。矛盾就来了：上面的 token 校验、角色判断、异常捕获、统一返回结构，我几乎在每个接口里都复制了一遍。最夸张的时候，改一个 token 过期判断逻辑，要全局搜索替换七八处。

1.2 重复代码带来的三个痛点

第一是维护成本爆炸。某个接口漏改，认证逻辑就跟其他接口不一致，前端一会儿收到 {"code": 401}，一会儿收到 {"detail": "Not authenticated"}，联调的时候被问得怀疑人生。

第二是安全漏洞风险。班级系统里有学生、教师、管理员三种角色，权限边界本来就细。手写校验最大的隐患是容易漏写。有一次“导出成绩单”的接口忘了加管理员判断，学生登录后直接传 student_id 就能拿到全班成绩，这种问题在代码评审里非常难发现，因为每个接口的校验代码长得差不多，review 的人很容易视觉疲劳。

第三是接口表现不一致。同样一个“无权限”错误，有的接口返回 HTTP 403，有的返回 HTTP 200 + code=403，前端 axios 拦截器很难统一处理。根治这个问题，必须把横切逻辑从业务代码里剥离出去。

1.3 为什么最终选了中间件而不是装饰器或依赖注入

很多同学第一反应是用装饰器。装饰器确实能解决“重复”的问题，但它有个明显的短板：只能作用在单个路由函数上，没办法在“请求进入路由之前”和“响应返回客户端之前”这两个更早或更晚的时机做统一处理。比如 CORS 跨域、访问日志、请求耗时统计、全局异常兜底，这些逻辑用装饰器会很别扭，而且路由函数一旦从装饰器里抛异常，处理起来非常被动。

FastAPI 的依赖注入（Depends）更适合处理“参数级”的复用，比如解析当前用户、校验分页参数。但它同样依赖你在每个接口里显式声明参数，做不到真正的“零侵入”。

中间件则完全不同。它挂在 ASGI 应用的最外层，顺序经过所有路由。请求进来时先过中间件，再进路由；响应返回时先经过路由，再经过中间件。登录校验、权限控制、请求日志、耗时统计、全局异常捕获，这些横切关注点放中间件里干，业务代码就变得非常干净。这也是我这次优化的核心思路。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. FastAPI中间件底层原理：搞懂执行顺序才能定方案

2.1 中间件在请求生命周期中的位置

要理解中间件，先看 FastAPI 处理一个请求的完整链路。客户端请求到达 Uvicorn 后，会依次经过服务端错误中间件、你注册的各个中间件、异常处理中间件，最后才进入路由匹配和端点函数。响应返回时顺序反过来。

这个顺序直接影响方案设计。比如日志中间件要记录完整耗时，就必须放在最外层；认证中间件要拦截未登录请求，就要放在路由之前；CORS 中间件要处理预检请求，就得放在认证外层，否则浏览器发 OPTIONS 预检请求会先被认证中间件拦截，跨域直接失败。

写代码之前先把这个链路搞清楚，后面能少踩很多坑。

2.2 BaseHTTPMiddleware 与纯 ASGI 中间件

FastAPI 官方文档推荐基于 starlette.middleware.base.BaseHTTPMiddleware 写中间件，重写 dispatch 方法就可以。我之前就是这么干的，写法简单，上手快：

python复制from starlette.middleware.base import BaseHTTPMiddleware

class MyMiddleware(BaseHTTPMiddleware):
    async def dispatch(self, request, call_next):
        # 请求前置处理
        response = await call_next(request)
        # 响应后置处理
        return response

不过后来压测发现，BaseHTTPMiddleware 在流式响应（比如下载 CSV、文件导出）场景下会有额外性能开销，因为 call_next 返回的 response 会被包装一层，流式内容可能被缓冲。如果不涉及大文件流式下载，这个差异可以忽略。但如果你追求极致性能，可以直接写纯 ASGI 中间件：

python复制class PureASGIMiddleware:
    def __init__(self, app):
        self.app = app

    async def __call__(self, scope, receive, send):
        if scope["type"] != "http":
            await self.app(scope, receive, send)
            return
        # 请求前置处理
        await self.app(scope, receive, send)
        # 响应后置处理

纯 ASGI 中间件更底层，控制粒度更细，但代码可读性差一些，对初学者不友好。班级管理系统内部用，BaseHTTPMiddleware 完全够用。实践下来，性能和可维护性之间的平衡点，我认为是“默认用 BaseHTTPMiddleware，遇到流式响应再单独换 ASGI”。

2.3 中间件执行顺序的“洋葱模型”

中间件的执行顺序是典型的洋葱模型。注册顺序靠前的中间件，请求阶段先执行，响应阶段后执行。我写了个最小化示例来验证：

python复制from starlette.middleware.base import BaseHTTPMiddleware

class OrderMiddleware(BaseHTTPMiddleware):
    def __init__(self, app, tag: str):
        super().__init__(app)
        self.tag = tag

    async def dispatch(self, request, call_next):
        print(f"请求进入: {self.tag}")
        response = await call_next(request)
        print(f"响应返回: {self.tag}")
        return response

app.add_middleware(OrderMiddleware, tag="one")
app.add_middleware(OrderMiddleware, tag="two")

访问任意接口，控制台输出是：

bash复制请求进入: one
请求进入: two
# 这里执行路由处理
响应返回: two
响应返回: one

也就是说，中间件一层套一层，像一个洋葱。这个特性在面试里也经常被问到——“FastAPI 中间件的执行顺序是什么”。实际工程里，我通常把日志中间件放最外层，这样统计到的“总耗时”最接近真实用户体验；把认证中间件放内层，避免对白名单接口做无意义的 token 解析。

3. 实战一：统一认证与权限管控中间件

3.1 班级系统三种角色的权限模型

班级管理系统的用户角色很典型：管理员、教师、学生。它们对接口的访问权限差异很大：

业务模块	学生	教师	管理员
查看个人成绩	是	是	是
录入成绩	否	是	是
修改班级课表	否	否	是
导出全班成绩	否	否	是
发布公告	否	是	是

以前这些权限判断散落在各个接口里，经常出现“学生调用教师接口”的越权问题。这次我把权限规则收敛到一个配置文件里，用中间件统一读取和判断。

3.2 从手写校验到中间件统一处理

认证中间件负责两件事：一是从请求头里解析并校验 token，把当前用户信息挂到 request.state.user 上；二是做接口级的权限判断。

python复制from starlette.middleware.base import BaseHTTPMiddleware

class AuthMiddleware(BaseHTTPMiddleware):
    async def dispatch(self, request: Request, call_next):
        path = request.url.path

        # 白名单接口直接放行
        if is_in_whitelist(path):
            return await call_next(request)

        token = request.headers.get("Authorization", "")
        user = verify_token(token)
        if not user:
            return JSONResponse(status_code=401, content={"code": 401, "msg": "未登录或登录已过期"})

        # 权限校验
        if not check_permission(user.role, path):
            return JSONResponse(status_code=403, content={"code": 403, "msg": "无权限访问"})

        request.state.user = user
        return await call_next(request)

中间件上线后，所有新接口默认都有认证和权限保护，不再依赖开发者的自觉。这个改动直接消掉了一个潜在安全漏洞类：漏写权限判断。

3.3 白名单机制与路径参数匹配

白名单是实现“免登录/免鉴权”的关键。像登录接口、验证码接口、健康检查接口，它们本身就是为了让用户拿到 token，不可能要求先带 token。我最初用 path in whitelist 做精确匹配，后来发现班级系统里有些路径带参数，比如“重置某个学生的密码”：

python复制# 错误示例：字符串完全匹配，带参数的路径匹配不上
WHITELIST = {"/api/v1/auth/login", "/api/v1/captcha"}
path = "/api/v1/students/1001/reset-password"

正确做法是定义规则，用正则或路径模板匹配。FastAPI 本身支持路径参数，路由里写的 {student_id} 其实对应 (?P<student_id>[^/]+)。我最后用 re.fullmatch 对路径做匹配：

python复制import re

WHITELIST_PATTERNS = [
    r"^/api/v1/auth/login$",
    r"^/api/v1/captcha$",
    r"^/api/v1/healthz$",
]

def is_in_whitelist(path: str) -> bool:
    return any(re.fullmatch(pattern, path) for pattern in WHITELIST_PATTERNS)

路径参数还有一个常见坑：权限判断时不同角色的可访问路径模式不同。比如教师可以访问 /api/v1/courses/{course_id}/students，学生不行。这些规则我会单独维护成角色到正则列表的映射，而不是把所有接口写死。

4. 实战二：接口返回格式统一与全局异常捕获

4.1 统一响应格式标准设计

班级管理系统前期最乱的的就是返回格式。有的接口直接返回裸列表，有的返回 {data: [], count: 0}，有的又包装成 {code, msg, data}。前端每次接新接口都要看后端文档猜结构。

我统一成固定格式：{"code": 0, "msg": "success", "data": ...}。业务正常时 code=0，业务异常时 code 存业务错误码，msg 存可读信息。data 字段最灵活，可能是对象、列表、字符串，甚至可能是空的，所以类型上要留余地：

python复制from typing import Union, Optional

class ApiResponse(BaseModel):
    code: int = 0
    msg: str = "success"
    data: Optional[Union[dict, list, str, int, float, None]] = None

这里 Union 的作用就体现出来了：它让 data 字段在类型检查阶段就允许承载多种数据结构，而不会触发 Pydantic 的类型校验错误。有些同学把 data 钉死成 dict，结果接口要返回 [1, 2, 3] 这种列表时直接报错，最后不得不把整个响应模型重写。

接口状态码设计上我采用了一个折中方案：HTTP 状态码只表示“请求是否被正确接收和处理”，业务状态永远通过 code 表达。也就是说登录失败返回 HTTP 200 + code=1001，而不是 HTTP 401。这样做的好处是前端拦截器逻辑简单，只需要判断 code，不需要同时兼顾 HTTP 状态码与业务错误。坏处是调试时网络面板里全是 200，但配合 msg 字段看也够用。

4.2 用异常处理器实现零侵入统一返回

中间件可以做统一返回格式，但更常用的组合是“自定义异常 + 全局异常处理器”。原因很简单：中间件拿到的是已经生成好的 response，如果想要改写响应体，还要读取 body、解析 JSON、重新包装，性能开销大而且容易出错。异常处理器则天然适合处理“正常返回之外”的场景。

我自定义了一个业务异常：

python复制class BizException(Exception):
    def __init__(self, code: int = 1000, msg: str = "业务异常"):
        self.code = code
        self.msg = msg

然后在 FastAPI 里注册全局异常处理器：

python复制from fastapi import FastAPI
from fastapi.responses import JSONResponse

app = FastAPI()

@app.exception_handler(BizException)
async def biz_exception_handler(request, exc: BizException):
    return JSONResponse(status_code=200, content={"code": exc.code, "msg": exc.msg, "data": None})

@app.exception_handler(Exception)
async def unhandled_exception_handler(request, exc: Exception):
    logger.error(f"未捕获异常: {exc}", exc_info=True)
    return JSONResponse(status_code=500, content={"code": 500, "msg": "服务器内部错误", "data": None})

这样业务代码里想返回“学生不存在”，直接 raise BizException(code=1002, msg="学生不存在")，异常处理器自动把响应包装成统一格式。不需要在接口里写 try-except，也不需要手动返回 {"code": ...}。

4.3 业务异常与未知异常的区分处理

班级系统项目里，已知的业务异常（如无权限、重复选课、成绩已录入）能列出一大堆，它们应该用 BizException 控制，返回 HTTP 200 + 业务 code。未知异常（如数据库连接断开、Redis 挂了）属于程序错误，应该走最后的兜底异常处理器，返回 HTTP 500 并记录完整堆栈。

有同学问“未知异常也返回 200 + code=500 不行吗”？理论上有项目这么干，但我不建议。因为监控告警系统通常依赖 HTTP 状态码判断服务健康状态，如果所有异常都返回 200，告警系统会认为服务一切正常，问题被隐藏到用户投诉才发现。让未知异常保持 HTTP 500，是给运维和监控留了一扇门。

5. 实战三：日志、耗时统计与请求ID链路

5.1 给请求加一个贯穿全程的 Request ID

排障的时候最头疼的就是用户反馈“我这边操作失败了”，但后台日志里全是并发请求，根本分不清哪条日志对应他的操作。我加了一个请求 ID 中间件：每个请求进来时生成一个 UUID，放进 request.state.request_id，然后把日志中间件、业务日志都打上这个 ID。

python复制import uuid

class RequestIDMiddleware(BaseHTTPMiddleware):
    async def dispatch(self, request, call_next):
        request_id = request.headers.get("X-Request-ID", str(uuid.uuid4()))
        request.state.request_id = request_id
        response = await call_next(request)
        response.headers["X-Request-ID"] = request_id
        return response

前端在发起请求时可以生成一个 X-Request-ID 传给后端，这样用户报障时把这个 ID 发过来，我直接到日志系统里一查，整个链路一目了然。

5.2 耗时统计的正确姿势

统计接口耗时是性能排查的基础。中间件非常适合做这件事，因为它包裹着整个路由处理过程：

python复制import time

class TimingMiddleware(BaseHTTPMiddleware):
    async def dispatch(self, request, call_next):
        start = time.perf_counter()
        response = await call_next(request)
        duration_ms = (time.perf_counter() - start) * 1000
        response.headers["X-Process-Time-MS"] = f"{duration_ms:.2f}"
        logger.info(
            f"请求耗时: {duration_ms:.2f}ms path={request.url.path} "
            f"status={response.status_code}"
        )
        return response

注意这里要用 time.perf_counter() 而不是 time.time()。time.time() 受系统时钟调整影响，可能在计时过程中跳变；perf_counter() 专门用于测量短时间间隔，精度高且不受系统时间修改影响。这个细节平时不显眼，但真排查问题时，毫秒级误差会干扰判断。

5.3 日志中间件放最外层，数据才完整

中间件有洋葱模型顺序，日志中间件我建议放最外层。原因很直观：日志要记录“整条请求链路”的完整耗时，如果放在内层，它只能统计到自己之后的时间，认证中间件里的耗时就被遗漏了。

外层日志中间件可以配合 request.state.user 记录操作人信息。认证中间件先运行并把用户信息挂到 state 上，日志中间件在响应阶段打印日志时，用户信息已经存在：

python复制logger.info(
    f"path={request.url.path} "
    f"user={getattr(request.state, 'user', None)} "
    f"request_id={getattr(request.state, 'request_id', '')} "
    f"duration={duration_ms:.2f}ms"
)

这样筛日志时按 request_id 查就能定位整条链路；按 user 查就能知道某个用户做了哪些操作。班级管理系统里有“家长反馈孩子成绩被改动”的投诉，我靠这个日志链路几分钟就能查出是哪个账号改的。

6. CORS与安全相关中间件的补充实践

6.1 CORS跨域处理的几种方式和坑

班级管理系统前后端分离，前端跑在 dev server 上，后端接口在另一个端口，跨域问题绕不开。FastAPI 自带 CORSMiddleware，配置很简单：

python复制from fastapi.middleware.cors import CORSMiddleware

app.add_middleware(
    CORSMiddleware,
    allow_origins=["http://localhost:5173", "https://admin.example.com"],
    allow_credentials=True,
    allow_methods=["*"],
    allow_headers=["*"],
)

最大的坑是 allow_origins=["*"] 和 allow_credentials=True 不能同时用。因为浏览器在携带 Cookie 的跨域请求中不允许 Access-Control-Allow-Origin: *，必须指定具体来源。班级管理系统后续加了单点登录，需要跨域携带 Cookie，这个配置就必须改成显式域名列表。

另一个容易被忽略的点是预检请求。浏览器跨域请求如果是非简单请求，会先发一个 OPTIONS 预检。如果 CORS 中间件没放在最外层，预检请求可能被认证中间件拦截返回 401，前端就报跨域错误，实际上后端日志里根本没有跨域配置的影子。

6.2 简易请求体大小限制

班级管理系统里学生提交作业附件、老师上传头像，文件大小很容易失控。如果不在网关层限制，大请求会拖垮后端。我在中间件层加了一个朴素的上限检查：

python复制class BodySizeMiddleware(BaseHTTPMiddleware):
    MAX_BODY_SIZE = 20 * 1024 * 1024  # 20MB

    async def dispatch(self, request, call_next):
        content_length = request.headers.get("Content-Length")
        if content_length and int(content_length) > self.MAX_BODY_SIZE:
            return JSONResponse(status_code=413, content={"code": 413, "msg": "请求体过大"})
        return await call_next(request)

这只是个快速拦截，真正的上传限流还应该配合文件流式处理。但对班级系统这个量级，中间件这个检查已经能把绝大多数异常请求挡在门外。

6.3 中间件注册顺序对安全策略的影响

中间件注册顺序不是小事。以我的项目为例，注册顺序是：

python复制app.add_middleware(LoggingMiddleware)      # 1. 日志，最外层
app.add_middleware(RequestIDMiddleware)     # 2. 请求ID
app.add_middleware(CORSMiddleware)          # 3. CORS
app.add_middleware(BodySizeMiddleware)      # 4. 请求体大小
app.add_middleware(AuthMiddleware)          # 5. 认证与权限

CORS 放在认证外层，保证预检请求不会被认证拦截；认证放在 CORS 内层，保证放行预检后，真正的业务请求还要过认证。日志在最外层，能记录到每一次请求，包括被认证拦截的非法请求。这个顺序一旦颠倒，就会出现“非法请求没日志”或“跨域预检失败”的问题。

7. 常见问题与调试实录

7.1 响应体被中间件“吞掉”了

有段时间前端反馈“接口返回 200，但 data 永远是空的”。查了半天发现是某个中间件在处理 response 时读取了 body，但没有重新构造响应：

python复制class BadMiddleware(BaseHTTPMiddleware):
    async def dispatch(self, request, call_next):
        response = await call_next(request)
        body = await response.body()  # 读了一次 body
        # 忘了把 body 写回去，直接 return response
        return response

BaseHTTPMiddleware 的 response 对象一旦读取了 body，后续浏览器拿到的响应体就变成空的。正确做法是把 body 存下来，重新构造一个 Response：

python复制from starlette.responses import Response

class GoodMiddleware(BaseHTTPMiddleware):
    async def dispatch(self, request, call_next):
        response = await call_next(request)
        body = await response.body()
        # 对 body 做处理...
        new_response = Response(
            content=body,
            status_code=response.status_code,
            headers=dict(response.headers),
            media_type=response.media_type,
        )
        return new_response

7.2 中间件里获取请求体后必须重新放回

认证、日志中间件有时候需要读取请求体（比如登录接口的账号密码）。但 Request.body() 读完之后，原始 body 会被消费掉，后续路由里再读 request.body() 或需要解析 form 数据就会拿不到内容。

实际上 Starlette 的 Request.body() 会缓存读取结果，第二次读取返回相同内容。但如果你用了流式读取或直接把 request.stream() 消费完，就可能出问题。我一般不会在中间件里读请求体，除非确有必要。确实需要时，我会这样处理：

python复制body = await request.body()
# 处理完后，手动恢复请求体缓存
request._body = body

注意 _body 是私有属性，这个做法本质上是在利用 Starlette 的缓存机制。更稳妥的方案是避免在中间件里读取请求体，把校验逻辑放到依赖注入里做。

7.3 异步与同步混用的坑

FastAPI 的中间件是异步的，如果你在中间件里调用同步阻塞操作，比如 requests.get()、同步数据库查询，会阻塞整个事件循环。班级系统早期有个版本号生成逻辑用了同步 MySQL 客户端，结果高并发时整个 API 全卡住。

解决方案有两个：一是把同步操作丢到线程池里执行：

python复制import asyncio

result = await asyncio.to_thread(sync_db_query, user_id)

二是干脆用 async 驱动。推荐后者，因为中间件的本质是 I/O 密集处理，异步化收益明显。

7.4 中间件异常导致链路中断

中间件里抛出的异常如果没被捕获，会导致整个请求链路中断。这种异常和路由里的异常不一样，路由异常会被全局异常处理器接管，但中间件异常发生在全局异常处理器之前，处理方式更麻烦。

我的做法是在最外层日志中间件里做兜底捕获：

python复制class LoggingMiddleware(BaseHTTPMiddleware):
    async def dispatch(self, request, call_next):
        try:
            response = await call_next(request)
            return response
        except Exception:
            logger.error("中间件链路异常", exc_info=True)
            return JSONResponse(status_code=500, content={"code": 500, "msg": "服务器内部错误"})

这样即使内部某个中间件出了问题，最外层还能兜住，不至于让连接直接断开。

8. 从“重复轮子”到“统一管控”的架构复盘

8.1 每个中间件只做一件事

这次优化最大的收获是学会了拆。中间件不是越多越好，而是职责越单一越好。我最终保留了六个中间件，每个只负责一件事：日志记录、请求ID、CORS、Body大小限制、认证、权限。如果有人想把“日志+认证+耗时+响应包装”塞进一个“万能中间件”，短期看代码是少了，但排查问题时会非常痛苦，因为一旦链路出错，你根本不知道是哪一段逻辑出了问题。

8.2 哪些场景不适合用中间件，反而要回归依赖注入

中间件不是银弹。有些场景用它反而更别扭。比如“获取当前登录用户”这件事，中间件把 user 挂到 request.state 上，路由函数里要写 request.state.user 才能拿到，类型提示也丢了。这种场景更适合用依赖注入：

python复制from fastapi import Depends

async def get_current_user(request: Request):
    return request.state.user

@router.get("/me")
async def get_me(user: User = Depends(get_current_user)):
    return user

这样既有类型提示，测试时也方便 mock。参数校验、Query 参数处理、ORM 会话管理也不适合放到中间件里，它们是“功能特性”而非“横切关注点”。

我总结的边界是：中间件处理“所有接口或大多数接口都要做的、与业务无关的通用逻辑”；依赖注入处理“少数接口需要复用的、跟具体业务参数相关的逻辑”。边界清晰，架构就不会乱。

8.3 给准备做中间件优化的同学三个建议

第一，先梳理再动手。别上来就写中间件。先把全部接口过一遍，统计哪些代码是重复的，哪些是真正个性化的。我当时用表格列了一个清单，每个接口标注“认证我写了吗、权限判断写了吗、异常捕获写了吗、统一返回写了吗”，然后按出现频次排序，优先抽离高频重复项。

第二，小步迁移，别一次性推倒重来。我当时先把新的中间件挂到测试环境，选几个接口验证结果。确认行为一致后，再逐步删除路由函数里的重复代码。如果一次性全改，出了问题根本不知道是哪个环节引起的。

第三，中间件要配套监控。统一管控之后，问题从“散落各处”变成了“集中在中间件”。如果中间件挂了，所有接口都会挂。所以我在最外层加了兜底异常捕获，同时把中间件自身的耗时也指标化。班级管理系统体量不大，但“最后一道防线”的思路是通用的。

回想这次优化，真正让我觉得值的地方不是删了多少重复代码，而是新同学接手项目时，看中间件注册顺序就能理解整个系统的认证、权限、日志链路。一个项目的最好状态，不是永远不写重复代码，而是让“注定要重复的横切逻辑”只在一个地方定义，然后所有接口都默默遵守。这就是我从“重复造轮子”到“统一管控”最核心的体会。以后写每个 FastAPI 项目，我都建议你先想清楚：哪些事应该由中间件统一做，哪些应该留给业务代码，这个边界越早划清，后面吃得苦越少。