校验应该放在哪里

前面三章的 schema，都是手动运行在上面几行现写的对象上。而真实的输入是通过网络到达的，schema 只有落在这种输入上才有意义。

问题在于把检查放在哪里，而这个位置会改变代码其余部分的写法。

一次提交经过的路径

一个注册表单向服务器发起 POST 请求。从请求到达到你的代码运行之间，会发生一件事：

text

form  ──POST──▶  validation  ──▶  route handler  ──▶  response
                     │
                     └──▶  400 with the errors

校验位于中间，由它决定请求会走向两种结局中的哪一种。

失败。 schema 发现了问题，请求就此止步，一个 400 Bad Request 会带着错误列表返回。路由处理函数根本不会运行。

通过。 解析后的数据继续流向路由处理函数，由它完成真正的工作，并以 201 Created 作答。

处理函数收到的数据，永远只会是已经通过 schema 校验的数据。

Juno一次提交经过的路径之前扫描仪的比喻依然适用，只是现在这台机器不再放在长椅上，而是立在了门口。

任何东西想进入门后的房间都必须经过它，房间也就不必再操心东西有没有被检查过。

为什么检查要放在前面

另一种做法是在每个路由处理函数的开头做校验，这样能跑通，但撑不住。

// 会逐渐走样的版本
import { registerSchema } from './schemas/userSchema.js'

app.post('/api/register', (req, res) => {
  const result = registerSchema.safeParse(req.body)
  if (!result.success) {
    return res.status(400).json({ success: false, errors: result.error.issues })
  }

  // ……真正的业务逻辑，早晚会写在这里
})

每个路由都要重复这段代码。而重复的代码会逐渐走样：一个路由对错误做了映射，另一个原样返回；一个忘了写 return，导致响应发出后处理函数还在往下执行；新的路由则随手复制了手边最近的那一份，不管它是不是最新的版本。

把检查放在前面，就能让所有路由共用同一份代码，也能让一个路由的校验规则从它的定义就能一眼看出来，而不必翻看函数体。

Juno为什么检查要放在前面两种写法运行的是同一个 schema，区别只在于周围那段代码存在了多少份。

一份代码，出了问题改一次就行；十二份代码，就得先找出哪一份出了问题。

处理函数收到的是什么

放在校验之后的处理函数可以写得很短，因为它可以直接假定拿到的数据是什么形状：

import { validate } from './middleware/validate.js'
import { registerSchema } from './schemas/userSchema.js'

app.post('/api/register', validate(registerSchema), (req, res) => {
  const userData = req.validatedData

  // 业务逻辑，处理的是已经通过 schema 校验的数据。

  res.status(201).json({ success: true, user: { email: userData.email } })
})

现在路径和处理函数之间有三样东西：validate(registerSchema) 就是那个检查，只有它通过了，处理函数才会运行。

处理函数读取的是 req.validatedData，而不是 req.body。这个区别就是整套安排的核心。req.body 是到达的数据；req.validatedData 是通过校验、并经过任何转换处理后留下的数据。

Juno处理函数收到的是什么两个名字，看起来像是同一样东西，但区别很重要。

req.body 是发送过来的原始内容。req.validatedData 是通过检查后留下的内容。只读第二个，处理函数就永远不用猜。

动手试试

下面这个路由在处理函数内部做校验：

import * as z from 'zod'
import { saveSubscriber } from './services/subscribers.js'

const subscribeSchema = z.object({
  email: z.email('请输入有效的邮箱地址'),
})

app.post('/api/subscribe', (req, res) => {
  const result = subscribeSchema.safeParse(req.body)

  if (!result.success) {
    res.status(400).json({ success: false, errors: result.error.issues })
  }

  const { email } = req.body
  saveSubscriber(email)

  res.status(201).json({ success: true })
})

找出其中的三个问题。

对照一下你的答案

1. 漏写了 return。 res.status(400).json(...) 发送响应后不会停止执行，所以一个无效请求会既收到 400，又被送进 saveSubscriber。客户端看到的是被拒绝，而订阅者却已经被保存了。

2. 读取的是 req.body 而不是 result.data。 就算修好了 return，用的仍然是原始值，这意味着 schema 里做的任何去空格、转小写处理都被扔掉了，schema 剔除掉的字段也都又回来了。

3. 原样返回了 result.error.issues。 Zod 的 issue 对象带着内部细节，包括期望的类型和失败的约束条件，它们的形状是给代码看的。而客户端需要的是"字段+消息"这样的配对。

还有第四个问题，在这个路由里还算不上 bug，但规模一大就会变成问题：所有这些逻辑都写在处理函数内部，下一个路由就会复制一份，而复制出来的版本会逐渐走样。

接下来往哪走

计划已经定了：处理函数前面放一道检查，失败时返回带有可用错误信息的 400，成功时把解析后的数据挂在请求上。

校验中间件会把它实现出来：一个函数，接收任意 schema，返回一个 Express 可以放在任何路由前面的东西。

校验应该放在哪里 ​

一次提交经过的路径 ​

为什么检查要放在前面 ​

处理函数收到的是什么 ​

动手试试 ​