Laravel的integer规则不拒绝字符串数字如"123"，因仅校验能否转int；string规则不拒绝空串、空白或null；boolean规则接受过多假值；验证规则顺序影响性能，应先轻量后查询类规则。
laravel validate integer 字段校验失败但没报错
常见现象是 integer 规则看似生效，但传入 "123"（字符串数字）或 null 时仍通过——因为 Laravel 默认不会强制类型转换，integer 实际只校验「能否被 cast 成 int」，不拒绝字符串形式的整数。
真正要严格区分类型，得配合 required|integer|numeric 或改用更明确的策略：
-
required|integer：允许"123"、123、-45，但拒绝"12.3"、"abc" -
required|digits_between:1,10：只接受纯数字字符串，长度 1–10，适合 ID、手机号等场景 - 如果必须拒绝字符串数字，得自定义规则或在控制器里先
filter_var($input, FILTER_VALIDATE_INT) !== false手动判断
laravel string 规则对空格和 null 的处理很隐蔽
string 规则本身不拒绝空字符串 ""、空白字符串 " " 或 null——它只确保值能转成字符串（连 false 都会变成 " "）。实际业务中这常导致意外入库空值。
安全做法是组合使用：
-
required|string|min:1：排除空字符串和纯空白（min:1会 trim 后计长度） -
required|string|regex:/^\S+$/：强制无空白字符（注意 PCRE 兼容性） - 若字段允许为空但不能为纯空格，用
nullable|string|trim+ 自定义逻辑清理，别依赖规则自动 trim
API 请求体里 boolean 字段校验不能只靠 required|boolean
Laravel 的 boolean 规则接受 true、false、"true"、"false"、"1"、"0"、1、0——范围太宽。前端发 {"active": "on"} 或 {"active": ""} 就会静默转成 false，而你根本不知道原始值是什么。
建议：
- 前端统一发
true/false布尔字面量，后端用required|boolean - 若必须兼容字符串，显式约定并校验：
in:true,false或in:1,0 - 避免把
boolean和nullable混用——null进来会被转成false，丢失“未设置”语义
laravel validation 性能坑：rule 顺序影响解析开销
规则执行是顺序短路的，但某些规则（如 exists:users,id、unique:posts,slug）会触发数据库查询。如果把它们放在前面，哪怕 required 都没过也会查库。
优化习惯：
- 把轻量规则放前面：
required|string|min:1，再放exists、unique - 对高频 API，考虑用
sometimes包裹条件性验证，避免无谓查询 -
array类型字段慎用*通配符规则（如items.*.id|required|integer），嵌套深了会显著拖慢验证器初始化
最麻烦的其实是前端传来的数据类型不可控——Laravel 不会主动把 "123" 转成 123，也不会把空字符串转成 null。校验规则只是“检查”，不是“修正”。真要类型干净，得在中间件或 Form Request 的 prepareForValidation() 里提前 cast，而不是指望 rule 自己扛。
