4.3 核心概念与中间件
4.3 核心概念与中间件
本节摘要：中间件是 Express 的灵魂。本节讲清中间件的概念（请求流水线上的处理函数）、next 的传递机制、常用中间件（日志、解析、静态文件）、以及"中间件顺序决定行为"的核心理解。
读前必看（上）
阅读完本节，你应当能够：
- 解释中间件的概念
- 理解 next 传递机制
- 使用常用中间件
- 掌握中间件顺序
- 编写自定义中间件
一、问题与直觉
"请求进来后发生了什么？"——在 Express 里，请求像过安检线：一个接一个的"检查站"（中间件）处理它，每个检查站可以"放行"（next）或"拦截"（返回响应）。日志、解析、鉴权都是检查站——这就是中间件机制。
二、核心原理
2.1 中间件的传递
app.use((req, res, next) => { console.log('请求来了:', req.path) next() // 放行到下一个中间件 })
2.2 常用中间件
| 中间件 | 作用 |
|---|---|
| morgan | 日志 |
| express.json | 解析 JSON |
| express.static | 静态文件 |
三、工程实践要点
3.1 中间件顺序的重要性
顺序决定行为： app.use(express.json()) → 先解析，路由才能拿到 body app.use(鉴权中间件) → 先鉴权，未登录直接拦截
💡 关键直觉：中间件是"排队处理"——顺序错了，行为就错。先写"通用处理"（解析、日志），再写"路由"，最后写"错误处理"。
3.2 自定义中间件
// 鉴权中间件示例 app.use((req, res, next) => { if (!req.headers.token) { return res.status(401).json({ error: '未登录' }) } next() })
⚠️ 常见坑：忘记调用 next。中间件不调用 next 也不返回响应，请求就会"卡住"——每个中间件要么 next，要么返回。
本章回顾
- 要点一：中间件 = 流水线上的处理函数
- 要点二：next 放行，返回即拦截
- 要点三：日志、解析、静态是常用件
- 要点四：顺序决定行为
- 要点五：自定义中间件做鉴权等逻辑
- 要点六：要么 next，要么返回
中间件会用了，下一节写接口——RESTful API 开发。
常见疑问
Q1：中间件到底是什么？一句话怎么说？
一句话：中间件是请求处理流水线上的函数，每个函数决定"放行（next）还是响应（结束）"。请求从进入应用开始，依次穿过注册的中间件，每个中间件都能读取请求、修改请求、提前返回响应，或调用 next 交给下一个。日志、鉴权、参数解析、错误处理，本质上都是中间件。理解这一个概念，Express 的机制就通了。
Q2：为什么中间件顺序很重要？
因为中间件是按注册顺序执行的，后注册的中间件要等前面的处理完（调用了 next）才会执行。顺序错了行为就错：比如鉴权中间件必须放在业务路由之前，才能拦住未登录请求；JSON 解析中间件（express.json）必须放在读取请求体的路由之前，路由才能拿到 body。写代码时先列一遍"哪些中间件必须在哪些之前"，是 Express 开发的基本功。
Q3：每个中间件必须 next 或返回吗？
是的，这是铁律。如果中间件既没调用 next、也没返回响应（结束请求），请求就"卡死"了——客户端一直等待，服务器日志无任何输出。写自定义中间件时，务必保证每条路径要么 next()，要么 res.xxx() 结束。这个 bug 排查起来很像"服务器没反应"，其实是请求悬在那了。
Q4：怎么用中间件做鉴权？
思路很直接：在路由之前挂一个鉴权中间件，检查请求头里的凭证（比如 token）。有凭证且合法就 next 放行；没有或非法就直接返回 401 状态码结束请求。业务路由不需要关心鉴权逻辑，中间件已经在前面拦过了。这就是中间件"横切关注点"的典型应用——鉴权、日志、限流这类公共逻辑，抽成中间件后每个路由自动复用，代码干净得多。
工程实践要点
动手建议：亲手验证"顺序决定行为"：写两个中间件，第一个打印"我是第一道"并 next，第二个打印"我是第二道"并 next，最后写一个返回 JSON 的路由。启动后观察控制台输出顺序，体会"请求穿过流水线"的过程。然后加一个鉴权中间件：请求头没有 token 就返回 401，有 token 才 next，测试未登录请求是否被拦下。再故意写一个"既不 next 也不返回"的中间件，观察请求卡死——教训比道理深刻得多。
实战演练：搭一条中间件流水线
本节练习的目标，是亲手搭一条"带日志、带鉴权、带业务"的完整中间件流水线。步骤如下：
第一步，搭最小流水线。注册三个中间件，分别打印"第一道、第二道、第三道"，最后写一个返回数据的路由。启动后访问接口，观察控制台输出顺序。验收标准：三行日志按注册顺序依次打印，路由正常返回数据。
第二步，加日志中间件。安装一个日志库（morgan）或用自带方法，记录每个请求的方法、路径、耗时。访问几个接口，观察日志输出。验收标准：每次请求都有日志记录。
第三步，加 JSON 解析中间件。在路由之前挂载解析 JSON 的中间件，然后写一个 POST 接口读取请求体。验收标准：POST 能拿到 JSON 数据；如果不挂载，请求体读不到——这个对比能加深你的理解。
第四步，写鉴权中间件。写一个检查请求头凭证的中间件，没有凭证就返回 401，有凭证才放行。分别用带凭证和不带凭证的请求测试。验收标准：不带凭证被拦截，带凭证能通过。
第五步，验证顺序影响。把鉴权中间件移到路由之后，再次测试不带凭证的请求——观察它是否还能被拦截。验收标准：你亲眼看到"中间件顺序决定行为"。
第六步，写错误处理中间件。在最外层挂一个捕获异常的中间件，让某个路由主动抛错，观察错误被统一处理、返回 500。验收标准：错误被兜住，而不是让进程崩溃。
六步走完，你亲手搭了一条完整的请求流水线，也踩过了"忘 next""顺序错"这些经典坑。中间件这个概念，从此不再抽象。
一句话记忆
中间件就是"请求穿过的一串处理函数"，每个要么放行要么响应。搭一条带日志、鉴权、解析、错误处理的流水线，你会彻底理解 Express 的运作方式，也能解释一半以上的 Express 疑难杂症。