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":"邮箱格式不正确"}。
- 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 这三类边界值。
php免费学习视频:立即使用
踏上前端学习之旅,开启通往精通之路!从前端基础到项目实战,循序渐进,一步一个脚印,迈向巅峰!











