Webman 表单验证需手动安装 webman/validation 扩展，无自动拦截和快捷方法；验证器只接受数组而非 Request 对象，规则为字符串格式，失败需主动判断；API 场景推荐 jeckleee/tools；校验须严格遵循五层顺序，且不自动类型转换。
webman/validation 必须 composer 安装才能用
直接 new Validator 或 use Validate 会报 Class not found，因为 Webman 核心不自带验证逻辑。官方推荐的 webman/validation 是独立扩展包，不是框架内置能力。
- 执行
composer require webman/validation安装，别漏掉webman/前缀 - 安装后无需发布配置或注册服务，
use support\Validate;即可调用 - 若项目已存在
respect/validation，两者共存无冲突，但规则语法不互通：前者用'email'字符串规则，后者用Validator::email()对象链 - 错误提示默认英文，中文需手动传
$messages数组，例如['email.email' => '邮箱格式不正确']
Validator::make() 传数组，不是 Request 对象
常见错误是把 $request 直接传给 Validate::make()，它只接受纯 PHP 数组（如 $_POST 或 $request->post()），不识别 PSR-7 请求对象。
- 正确写法：
$data = $request->post(); $validator = Validate::make($data, $rules); -
$rules是关联数组，键为字段名，值为管道分隔的字符串规则，例如'age' => 'required|integer|min:18' - 规则中
required判空用的是empty()，所以0、"0"、false、[]都算缺失——业务若允许数字0，得改用requiredIf(fn($d) => isset($d['age'])) - 验证失败不抛异常，要主动调
$validator->fails()判断，再取$validator->errors()->all()
jeckleee/tools 更适合 API 场景
如果你做的是前后端分离项目，需要 JSON 响应 + 全量错误提示 + 链式规则，jeckleee/tools 比原生 webman/validation 更省事。
- 安装后必须运行
php webman vendor:publish --provider="Jeckleee\Tools\ServiceProvider"，否则类找不到 - 初始化是
$v = \Jeckleee\Tools\Validator::make($data)，然后链式加规则：->required('email')->email('email')->strLength('name', 2, 20) - 默认
stopOnFirstFailure(true)，只返回第一个错；API 建议设为false，一次性返回全部字段错误 - 自定义异常类必须实现
__toString()，否则$e->getMessage()只返回 "Validation failed"，看不到具体字段
别在控制器里手写 if-else 校验
Webman 的五层校验顺序（存在性 → 类型 → 长度 → 业务 → 权限）不是建议，是防止脏数据入库的硬约束。把数据库查重放在 required 前面，等于让空值绕过第一关直连 DB。
立即学习“PHP免费学习笔记（深入）”；
- L1 存在性必须用
required或array_key_exists()，不能靠isset($data['x'])—— 因为isset(null)是 false，但isset('')是 true - L2 类型校验必须在 L1 之后，否则对
null调email()规则可能返回意外 true（某些验证器对 null 宽松） - L4 业务校验（如用户名是否已存在）必须查库，成本高，绝对不能放验证器规则里写成
'username' => 'required|unique:users'—— 这是 Laravel 风格，Webman 原生不支持 - 所有校验都应在中间件或控制器方法开头完成，不能混在业务逻辑中间
$data 不会被自动过滤或转换类型，integer 规则只校验，不 cast；string 规则允许 "123" 通过，但不会帮你转成字符串。这些都得自己补一层处理。 
