Webman参数校验器实践优雅地过滤和验证前端输入数据-php教程-PHP中文网

校验必须分五层且顺序不可颠倒：l1存在性、l2类型格式、l3长度范围、l4业务合法性、l5权限约束；推荐jeckleee/tools，需正确配置并注意strlength须配合required使用。

webman参数校验器实践优雅地过滤和验证前端输入数据

Webman 里参数校验不是“有没有”的问题，而是“在哪做、按什么顺序做、用哪个工具做”才不翻车。直接上结论：别在控制器里写 if (!isset($data['xxx']))，也别把数据库查重放在必填判断之前——校验顺序错了，轻则响应慢，重则脏数据入库、下游崩盘。

所有参数进入业务逻辑前，必须过五道关，且顺序不可颠倒。这是性能和安全的双重底线：

L1 — 存在性检查：字段是否传了？值是不是 null、空字符串、[]。用 required 规则或手动 array_key_exists() 判断。这步最轻，必须最先执行。
L2 — 类型与格式：比如 email 字段传了 "abc"，age 传了 "twenty"，这时该用 filter_var($v, FILTER_VALIDATE_EMAIL) 或验证器的 email()、integer() 规则拦截。
L3 — 长度与范围：用户名长度 2–20、价格必须 ≥ 0、日期不能早于 2020-01-01。这类规则依赖 L2 已确认类型，否则对字符串调 max:100 没意义。
L4 — 业务合法性：如 category_id 是否存在于数据库、password 和 confirm_password 是否一致。这步要查库或比对，成本高，必须等前面都通过再跑。
L5 — 权限与上下文约束：比如当前用户能否操作该订单、该 token 是否已绑定设备。这步通常在中间件或服务层做，不在验证器内硬编码。

它不改框架、不侵入路由、不强制继承，纯函数式链式调用，适配 Webman 的 request 生命周期最自然。但要注意几个实操坑：

PigX UI 前端开发

PigX UI Pro 前端开发指南 - Vue 3 + TypeScript + Element Plus。当用户提到 PigX UI、PigX 前端、lgb-mgui 项目、Vue 3 企业级后台开发、Element Plus 后台开发时使用此技能。

下载

安装后必须发布配置：php webman vendor:publish --provider="Jeckleee\Tools\ServiceProvider"，否则 Validator::make() 会报类未找到。
strLength('username', 2, 20) 对空字符串返回 true，得配合 required('username') 一起用，单独用会漏掉空值。
自定义异常类必须实现 __toString() 或重写 getMessage()，否则 JSON 响应里只显示 "Validation failed"，没具体字段信息。
批量验证时，validate() 默认只返回第一个错误；要全量错误，得加 ->stopOnFirstFailure(false)。

如果你项目里大量沿用 ThinkPHP 8.x 的规则写法（比如 alphaNum|min:3|max:16），Wekyun/Tool 几乎零学习成本。但它有个隐藏约束：

必须手动创建 config/wekyun.php，且 'mapping' 里指定的验证类路径要严格匹配命名空间，比如 ppalidateUserValidate::class 对应文件是 app/validate/UserValidate.php，少一个字母就 Class not found。
$req->checkAll(['a','b','c']) 默认只做存在性 + 类型转换（如把 "1" 转成 int），不触发规则校验；要走规则，得显式调 $req->validate(['a' => 'required|email'])。
错误码固定为 203，如果项目已用其他错误体系，得在 wekyun.php 里重写 'err_func' 回调，否则前端无法区分是参数错还是业务错。

如果你的 Webman 项目早期就用了 webman/validator，且控制器里全是 new UserRegisterValidator($request->all()) 这种写法，继续沿用它没问题。但注意两个关键点：

rules() 返回的数组里，| 分隔的规则是**顺序执行**的，'username' => 'required|alpha_num|min:3' 中，required 失败就不会进 alpha_num，所以字段名重复写规则不会叠加，别指望 required|email|required 能强化校验。
messages() 里的 key 必须和规则完全对应，比如写了 'username.required' => '用户名必填'，但规则是 'user_name.required'（下划线），那提示永远不会生效。
它不支持嵌套数组校验（如 address.city），遇到 JSON body 里带层级的数据，得先 flatten 或换用 jeckleee/tools。