后端
中间件Middleware
你可能会问
中间件到底是什么？请求在见到业务逻辑之前，都过了谁的手？
简单来说
在请求到达核心逻辑前后执行的通用处理，例如鉴权、日志或限流。
一个请求进入通道
GET/orders
凭证🎫 有效
过完公用的关，才见业务
01 · 先这样理解
把抽象概念放进真实场景
在请求到达核心逻辑前后执行的通用处理，例如鉴权、日志或限流。
换个角度想中间件像机场的安检通道：不管你飞哪儿，都先过同样几道关——查身份、称行李、留记录。目的地各不相同，通道却是公用的：一次搭好，所有航班共享。
02 · 点击演示
一个请求，要过几道公用的关？
突出显示的部分，就是当前概念在整条流程中负责的位置。
- GET /orders
凭证🎫 有效（没有） - 凭证有效——放行，下一关401 · 没有凭证——原路返回
log: user_42 GET /orders
顺手记一笔，继续往前
没走到这一关——
请求在鉴权时已被送回- 200业务逻辑收到请求穿过通道的，才见得到它401业务代码毫不知情这正是中间件的价值：脏活累活挡在门外
1 / 4
Enter · 请求进入通道
03 · 放进真实任务
什么时候会遇到它
统一鉴权
登录校验写一次，所有要保护的 endpoint 共享。
统一记录
日志和耗时统计在通道里顺手完成，业务代码保持干净。
统一限流
同一个来源请求太猛？在通道口就拦下，别打进业务。
04 · 想一想
用一个问题检查理解
十个 endpoint 都需要登录才能访问。把校验代码复制十份，还是有更好的办法？
查看答案
写一个鉴权中间件，挂在这十个 endpoint 前面。校验逻辑只有一份，改一次全体生效——和组件「一处修改、处处生效」是同一个道理。
最容易踩的坑
中间件的顺序就是流水线的顺序：日志放在鉴权前还是后，记下来的东西完全不同。加中间件时，想清楚它站在队伍的第几位。