校验必须分五层且顺序不可颠倒：L1存在性、L2类型格式、L3长度范围、L4业务合法性、L5权限约束；推荐jeckleee/tools，需正确配置并注意strLength须配合required使用。
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 是否已绑定设备。这步通常在中间件或服务层做，不在验证器内硬编码。
jeckleee/tools 是 Webman 最省心的验证器选型
它不改框架、不侵入路由、不强制继承，纯函数式链式调用，适配 Webman 的 request 生命周期最自然。但要注意几个实操坑：
- 安装后必须发布配置：
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)。
Wekyun/Tool 更适合已有 TP 验证习惯的团队
如果你项目里大量沿用 ThinkPHP 8.x 的规则写法（比如 alphaNum|min:3|max:16），Wekyun/Tool 几乎零学习成本。但它有个隐藏约束：
PigX UI 前端开发
下载
PigX UI Pro 前端开发指南 - Vue 3 + TypeScript + Element Plus。当用户提到 PigX UI、PigX 前端、lgb-mgui 项目、Vue 3 企业级后台开发、Element Plus 后台开发时使用此技能。
立即学习“前端免费学习笔记（深入）”；
- 必须手动创建
config/wekyun.php，且'mapping'里指定的验证类路径要严格匹配命名空间，比如pp alidateUserValidate::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'回调，否则前端无法区分是参数错还是业务错。
FormValidator 扩展适合强表单结构的老项目
如果你的 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。
真正容易被忽略的，是 L4 层查库动作的副作用——比如校验手机号唯一性时，如果没加数据库唯一索引，光靠 SELECT 判断，高并发下照样插入重复。校验器再优雅，也得和 DB 约束对齐。
