Webman 中 Validator 类直接 new 初始化，不依赖容器；传数组数据、链式加规则、调 validate() 验证；error_return_mode=immediate 返回首个错误，collective 返回全部错误；requiredWith/Without 用 empty() 判空，0/"0"/false/[] 均视为空；strAlphaNum(true) 要求字母数字混合。
Webman 中 Validator 类怎么初始化和调用
直接 new Validator 实例即可，不需要依赖容器或特殊注册。它不绑定请求对象，是纯数据验证器，适合 API 接口、后台逻辑、命令行等任意场景。
常见错误是误以为要像 Laravel 那样通过 $request->validate() 调用，或者试图在控制器里注入 Validator 实例——它不是服务，没有绑定到容器。
- 正确写法：
$v = new \Jeckleee\Tools\Validator(); - 传入待验证数据（数组）：
$v->setData($data) - 添加规则链：
$v->required('username')->strLength(2, 20)->strAlphaNum(true) - 执行验证：
$v->validate()，成功返回true，失败抛异常（由配置决定类型）
error_return_mode=immediate 和 collective 的实际影响
这个配置决定你收到的是「第一个错」还是「所有错」，直接影响前端提示体验和后端调试效率。
immediate 模式下，只要 username 为空，就不会再检查 email 是否合法；而 collective 会跑完全部字段，最后抛出一个包含所有错误的 JSON 字符串，比如：{"username":"用户名不能为空","email":"邮箱格式不正确"}。
立即学习“PHP免费学习笔记（深入）”；
- API 开发建议用
collective：前端一次拿到全部提示，避免反复提交 - 敏感字段（如支付密码）可临时切回
immediate：防止错误信息泄露过多校验逻辑 - 注意：若配置值拼写错误（如写成
collect），会直接抛异常中断，不 fallback
requiredWith 和 requiredWithout 容易被忽略的空值判定逻辑
这两个规则判断「指定字段是否存在且不为空」时，用的是 PHP 的 empty()，不是 isset() 或 !is_null()。这意味着 0、"0"、false、[] 都算「空」。
例如：requiredWith('coupon_code')，当 coupon_code = "0" 时，该字段会被视为不存在，当前字段就跳过验证——这在优惠券码为纯数字时极易踩坑。
- 若业务中允许
"0"作为有效值，改用requiredIf(fn($data) => isset($data['coupon_code']))手动控制 -
requiredWithout('phone')对应同理：只要phone是0或"0"，就会触发「必填」逻辑 - 调试时可用
var_dump($data)确认原始值类型，避免字符串和整数混用导致判断偏差
strAlphaNum(true) 中的 true 参数到底做什么
这个 true 不是开关，而是「强制混合要求」：开启后，字符串必须**同时包含至少一个字母和至少一个数字**，缺一不可。
比如：strAlphaNum(true) 会拒绝 "abc"（无数字）、"123"（无字母）、" "（含空格），但接受 "a1"、"pass99"、"X2yZ"。
- 设为
false或省略，则退化为「只允许字母+数字」，等价于正则/^[a-zA-Z0-9]+$/ - 该规则不会自动 trim，如果前端没处理空格，
"abc123 "会因末尾空格失败——需前置加strTrim() - 中文、下划线、连字符全都不支持，哪怕
strAlphaNum(false)也不行
真正难搞的不是规则写不对，而是空值判断逻辑和 error_return_mode 的组合效果——改一个配置，可能让前端从「逐条提示」变成「全量报错」，而开发者还在查 JS 控制台有没有拦截到响应。务必在接口文档里明确标注验证模式，并在测试用例里覆盖 0、"0"、null 这三类边界值。
