laravel嵌套数组验证需严格匹配结构：固定字段用'key.subkey.field'规则，动态数组用'key.*.field'，rule::foreach闭包参数为($value,$key)，条件规则不支持跨层，前后端数组形态必须一致。
验证嵌套数组字段时规则写法不对，直接报错 Array to string conversion
这是最常踩的坑：Laravel 的 validate() 方法默认把点号（.）当层级分隔符，但如果你传入的是 PHP 多维数组（比如前端用 name="user[profile][age]" 提交），而验证规则里写成 'user.profile.age' => 'required|integer'，Laravel 就会试图把整个 user 数组转成字符串——然后崩。
正确做法是用星号通配符或明确展开：
- 对固定结构（如
user.profile.age），规则键名必须跟实际数组键完全一致：'user.profile.age' => 'required|integer'，且请求数据里$request->user必须是嵌套数组，不是对象 - 对动态数组（如多个
tags[]），用*占位：'tags.*.name' => 'required|string'，此时$request->tags应是索引数组，如[0 => ['name' => 'a'], 1 => ['name' => 'b']] - 别在规则里对顶层键加
array类型校验再套点语法，比如'user' => 'array', 'user.profile' => 'array'是冗余的，'user.profile.age'自动隐含了前两级存在且为数组
使用 Rule::forEach() 动态生成规则时，闭包参数顺序容易搞反
Laravel 9+ 引入的 Rule::forEach() 是处理“每个子项需不同逻辑”的利器，但闭包第一个参数是当前值（$value），第二个才是键（$key），很多人按 foreach 习惯写成 function ($key, $value)，结果 $key 变成数组元素、$value 变成索引，规则全乱。
典型场景：用户提交多个文件，每个要单独验 MIME 和尺寸：
use Illuminate\Validation\Rule;
$rules = [
'files' => 'required|array',
'files.*.path' => 'required|string',
'files.*.size' => 'required|integer',
];
$rules['files.*'] = Rule::forEach(function ($value, $key) {
return [
'path' => 'required|string',
'size' => 'required|integer|min:1024',
'mime' => 'required|string|in:pdf,docx',
];
});
注意：这个闭包会在每个 files.X 子数组上执行，$value 是该子数组本身（如 ['path'=>'a.pdf','size'=>2048]），$key 是索引（如 0）。别反着用。
required_if 和 required_unless 在嵌套字段里失效
这些条件规则只认“同级字段”，不支持跨层判断。比如你写 'user.profile.bio' => 'required_if:user.profile.has_bio,1'，Laravel 会去查 $data['user']['profile']['has_bio']，但验证器内部并不保证这个路径一定被解析为独立字段——它可能被当成一个扁平 key 处理，导致条件永远不触发。
安全做法只有两种：
- 把依赖字段提到同一层级，比如改用
'user_profile_has_bio' => 'boolean'，再写'user.profile.bio' => 'required_if:user_profile_has_bio,1' - 自定义规则，用
$validator->getData()手动取嵌套值判断，例如：
use Illuminate\Support\Str;
$rules['user.profile.bio'] = [
'string',
function ($attribute, $value, $fail) use ($validator) {
$hasBio = data_get($validator->getData(), 'user.profile.has_bio');
if ($hasBio && empty($value)) {
$fail(':attribute is required when has_bio is true.');
}
}
];
表单数组命名和后端验证结构必须严格对应
前端 name 属性怎么写，后端就怎么收，验证规则就怎么配。没有自动“智能映射”。常见断层点：
- 前端写
name="items[][id]"→ 后端收到$request->items是索引数组，规则用'items.*.id' - 前端写
name="items[0][id]"→ 还是索引数组，但缺了1项会导致items.*跳过，得用'items.*.id' => 'nullable'或确保连续索引 - 前端写
name="settings.theme"→ 后端$request->settings是对象？不行。Laravel 只处理数组，必须是['theme' => 'dark']，否则settings.theme规则无效 - Vue/React 提交 JSON 时，如果没设
Content-Type: application/json，Laravel 当作普通表单解析，{ "user": { "name": "A" } }会变成字符串，不是数组
多维验证真正卡住人的地方，从来不是语法记不住，而是前后端对“数组形态”的理解错位。盯住 $request->all() 输出看一眼，比查文档快十倍。
