后端【免费下载链接】express-validatorAn express.js middleware for validator.js.项目地址https://gitcode.com/gh_mirrors/ex/express-validator点击查看免费下载express-validator 的设计哲学是声明式的把校验链Validation Chain作为中间件直接传给 Express 路由由框架替你调度执行。但在实际业务中我们常常需要自己掌控校验的时机——例如先做业务判断再决定是否校验、把多个校验聚合成统一的错误响应、或在同一请求中按条件追加校验。本篇技术指南将围绕 feature-running-imperatively.md 所讲的run(req)命令式运行方式讲解它的 API 契约、底层实现原理并给出可复制的实战封装方案让你读完后能独立实现自定义校验执行器与条件化校验。为什么需要命令式运行校验express-validator 默认推崇的是 Express 中间件式的声明式写法body(email).isEmail()这样的校验链本身就是一个中间件直接放进路由参数数组即可框架会在请求进入路由前自动执行它。这种写法简洁直观覆盖了绝大多数场景。但有些场景下你希望对校验的执行时机拥有完全的控制权统一错误响应格式多条校验链分散执行错误需要聚合后统一返回而不是依赖每个中间件各自的处理条件化校验例如当请求中提供了密码时才必须同时提供密码确认字段这类依赖请求内容动态决定校验与否的逻辑放在路由处理器内部用命令式写法表达最自然复用与编排把一组校验包装成可复用的工厂函数在不同路由中按需调用。run(req)就是为此设计的入口。它定义在ContextRunner接口上由校验链、净化链以及checkExact()、checkSchema()、oneOf()等产物共同实现。在 src/chain/context-runner.ts 中可以清晰地看到这个接口的契约export interface ContextRunner { run(req: Request, options?: ContextRunningOptions): PromiseResultWithContext; }其中ContextRunningOptions目前只有一个dryRun选项默认false用于决定是否把错误与净化结果持久化回req。也就是说run(req)返回的是一个解析为Result对象的 Promise——你可以await它然后自行决定如何处理错误。案例一封装可复用的统一校验执行器标准化错误响应最常见的命令式用法是把若干条校验链收集成数组逐个run(req)执行再统一从req中提取错误并返回标准化的 JSON 响应。这样写出的validate工厂函数可以被任意路由复用const validate validations { return async (req, res, next) { await Promise.all(validations.map(validation validation.run(req))); const errors validationResult(req); if (errors.isEmpty()) { return next(); } res.status(400).json({ errors: errors.array() }); }; }; app.post(/api/create-user, validate([ body(email).isEmail(), body(password).isLength({ min: 6 }) ]), async (req, res, next) { // 走到这里请求已经保证不携带任何校验错误 const user await User.create({ ... }); });要点说明Promise.all会让所有校验链并行执行如果你希望前一条失败即停止后续校验顺序执行、短路退出可以改用for...of循环并检查每次run(req)返回的Result是否isEmpty()如下所示const validate validations { return async (req, res, next) { for (const validation of validations) { const result await validation.run(req); if (!result.isEmpty()) { return res.status(400).json({ errors: result.array() }); } } next(); }; };每次run(req)都会把本次校验的上下文Context写入req上由contextsKey即express-validator#contexts定义见 src/base.ts标记的内部数组随后validationResult(req)会把该数组里所有 Context 的errors扁平化汇总成最终的Result。这就是错误聚合能够生效的底层机制相关实现可查阅 src/validation-result.ts 中的withDefaults函数与 src/chain/context-runner-impl.ts 中的ContextRunnerImpl.run()。深入run(req)的底层执行流程从 src/chain/context-runner-impl.ts 的源码可以看到一次run(req)大致经历以下步骤若传入的是ContextBuilder先build()生成Context否则直接使用已有Context检查请求中是否已存在bail且带错误的上下文——若存在则直接短路返回空结果这是对全局bail()语义的承接通过selectFields()依据Context中登记的字段与位置body/query/params/cookies/headers从请求中挑选出字段实例按context.stack中校验项validator、sanitizer、custom 等的注册顺序逐个执行同一层的多个字段实例通过Promise.all并行处理校验项执行过程中若某个实例的值被净化器修改且未开启dryRun新值会被写回req[location][path]执行完毕后把Context追加进req[contextsKey]数组最后返回一个携带该 Context 的ResultWithContext。这也解释了文档中的一条关键经验链是可变的mutable——每次调用.isEmail()、.withMessage()等都会向同一个ContextBuilder追加行为因此若要在多处复用某条基础链应使用工厂函数每次生成新链避免状态相互污染。深入错误对象的结构默认情况下Result.array()与Result.mapped()返回的错误对象具有如下结构可参见 website/versioned_docs/version-6.3.0/api-validation-result.md{ msg: The error message, param: param.name.with.index[0], value: param value, // 产生该错误的参数位置body、query、params、cookies 或 headers location: body, // nestedErrors 仅在使用了 oneOf 时存在 nestedErrors: [{ ... }] }如果你想定制输出格式validationResult还提供withDefaults({ formatter })或Result.formatWith(formatter)两种方式Result对象本身则暴露了isEmpty()、array({ onlyFirstError })、mapped()、throw()等方法实现见 src/validation-result.ts足以支撑你构建任何形状的错误响应。案例二条件化校验——在路由处理器内部按需运行另一个典型场景是基础字段先以中间件形式校验而某些依赖其他字段存在与否的校验需要在路由处理器中拿到请求体之后动态决定是否执行。run(req)让这种写法成为可能app.post(/update-settings, [ body(email).isEmail(), body(password).optional().isLength({ min: 6 }) ], async (req, res, next) { // 如果请求提供了密码那么必须同时提供密码确认字段 if (req.body.password) { await body(passwordConfirmation) .equals(req.body.password).withMessage(passwords do not match) .run(req); } // 检查校验错误然后更新用户设置 const errors validationResult(req); if (!errors.isEmpty()) { return res.status(400).json({ errors: errors.array() }); } // ...更新逻辑 });这里的关键是body(passwordConfirmation)会构造一条全新的校验链而run(req)则把它立即执行并写入同一份req的错误集合因此后续validationResult(req)依然能聚合到它产生的错误。用matchedData(req)获取净化后的字段值而不是直接读req.body.password是更稳健的做法可以避免校验前的原始值污染判断逻辑。官方建议优先使用.if()声明式条件需要强调的是上述条件化校验只是一个演示命令式用法的示例。当你需要的是按条件决定某条链是否继续校验时应当优先使用校验链自带的.if(condition)方法以声明式的方式表达条件例如body(oldPassword) // 当提供了新密码时…… .if((value, { req }) req.body.newPassword) // ……旧密码也必须提供…… .not().empty() // ……且两者不得相同 .custom((value, { req }) value ! req.body.newPassword).if()接受一个自定义校验风格的函数或另一条校验链body(newPassword).exists()从 src/context-items/chain-condition.ts 的实现可以看到它会先运行条件链若条件产生错误则跳过后续校验项。命令式run(req)的价值在于运行时完全由你编排而.if()的价值在于声明式的自包含条件——两者各司其职按场景选用。适用边界与注意事项run(req)也可用于净化链Sanitization Chain净化链同样实现了ContextRunner接口你可以await sanitizeBody(email).normalizeEmail().run(req)净化后的值会被写回req.body除非传入{ dryRun: true }只做检查不落地。多次run(req)与validationResult的聚合语义validationResult汇总的是req上已注册的所有 Context的错误无论它们来自中间件式声明还是命令式run(req)。因此混合使用两种风格是安全的但要注意链的可变性——尽量在每次run(req)前现场构建新链。run(req)返回的 Promise 需要被 await每个字段实例的执行都是异步的支持 promise 形式的自定义校验器遗漏await会导致错误尚未写入req时就去读取结果。版本适用性本文以仓库中的 6.3.0 版本文档website/versioned_docs/version-6.3.0/feature-running-imperatively.md为基准展开其后的 docs/guides/manually-running.md 是当前版本对应的同类指南写法略有演进如ContextRunner类型显式化、推荐matchedData新版读者可对照阅读。ContextRunner接口与run()的返回类型定义以 src/chain/context-runner.ts 为准。小结命令式运行校验是 express-validator 声明式风格的重要补充通过run(req)你既可以把多条校验链聚合进自建中间件以统一错误响应也可以在路由处理器内部按业务条件动态追加校验。理解它背后的ContextRunner契约、req[contextsKey]错误聚合机制以及链可变、用工厂函数复用的原则能让你在构建复杂表单校验、动态安全策略等场景时游刃有余。需要进一步了解run(req)与其他校验链方法的完整组合可继续阅读 validation chain API 与 validationResult API。赞分享后端【免费下载链接】express-validatorAn express.js middleware for validator.js.项目地址https://gitcode.com/gh_mirrors/ex/express-validator点击查看免费下载相关推荐express-validator 命令式校验指南用 run(req) 将校验控制权掌握在自己手中express validator 命令式校验指南用 run req 将校验控制权掌握在自己手中 express validator 默认推崇 Express后端SQLFluff 安全防护指南三层权限模型下的沙箱、解析限额与 library_path 加固SQLFluff 安全防护指南三层权限模型下的沙箱、解析限额与 library_path 加固 SQLFluff 是一款模块化的 SQL 解析器与自动格式化工后端express-validator 命令式验证指南用 run(req) 手动掌控验证流程express validator 命令式验证指南用 run req 手动掌控验证流程 express validator 默认推荐声明式的中间件写法把验证后端上一篇掌握create-better-t-stack构建现代TypeScript项目的终极Monorepo指南下一篇从零开始构建大语言模型Build-A-Large-Language-Model-CN 完整指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考