1. 场景与目标
嵌套数组的实际场景
在 Laravel 项目中，常见需要一次性接收多条用户数据，每条包含邮箱和角色信息，这就是嵌套数组的典型场景。正确的嵌套校验可以避免无效数据进入数据库，提升数据一致性。
另一种场景是一个表单提交多个成员信息，例如团队成员的邮箱和角色集合。采用点记法和通配符匹配可以高效地对每一项进行验证，从而实现批量处理。
要点回顾
在设计验证规则时，应将目标字段分层：外层必须是数组，内层每个元素应包含 email 与 roles。使用 Laravel 的数组规则可以逐层验证，并尽量在 FormRequest 内集中规则定义以提升可维护性。
2. Laravel 验证基础
基础规则与数据结构
Laravel 的验证遵循 rules 数组形式，键名使用点记法来表达深层字段。对于嵌套数组，使用 users.*.email 之类的模式进行逐项校验。
数据结构需要定义为一个对象数组，每个对象至少包含 email 和 roles 字段。确保数据结构符合规则有助于后续错误信息可读，并且便于前端给出友好的提示。
规则组合示例
常用的组合包括 required、array、email、min、in、distinct 等。组合规则可自定义以满足业务约束，例如确保每个用户有且只有一个主要角色或多角色都在允许集合内。
// 基础嵌套数组的验证规则示例
$rules = ['users' => 'required|array','users.*' => 'array','users.*.email' => 'required|email','users.*.roles' => 'required|array|min:1','users.*.roles.*' => 'in:admin,editor,viewer',
];3. 验证嵌套数组中的邮箱字段
邮箱字段的校验要点
在嵌套结构中，邮箱字段常见路径为 users.*.email，需要同时满足格式与存在性。使用 email 规则可以确保符合邮箱格式，而 required 确保不为空。
为了防止同一组嵌套对象中的邮箱重复，可以在规则层面结合 distinct 或在后续阶段进行重复性检查。现阶段可先进行格式与必填校验，再结合自定义逻辑处理重复问题。
具体规则写法
在验证时应将外层设为数组，内层元素再逐项验证邮箱字段。点记法配合通配符是处理嵌套字段的核心。
$rules = ['users' => 'required|array','users.*.email' => 'required|email',// 其他字段规则
];嵌套邮箱重复性的处理示例
若要确保同一请求中的邮箱不重复，可以在验证完成后进行自定义检查，下面的示例演示了如何在 after 回调中捕获并提示重复邮箱信息。结合 after 回调可以实现复合校验。
$validator = Validator::make($data, ['users' => 'required|array','users.*.email' => 'required|email',
]);$validator->after(function ($validator) use ($data) {$emails = collect($data['users'] ?? [])->map(function($u) { return $u['email'] ?? null; })->filter()->toArray();if (($count = count($emails)) !== count(array_unique($emails))) {$validator->errors()->add('users.*.email', 'Emails must be unique across all users.');}
});if ($validator->fails()) {// 处理错误
}4. 验证嵌套数组中的角色字段
角色字段的规则设计
角色字段通常为一个数组：roles，位于每个用户对象内，如 users.*.roles。需要至少一个角色且每个角色值需来自允许集合。
常见做法是将 roles 设定为必选且为数组，再对每个元素做取值限制，例如 admin、editor、viewer 等。
多角色取值的校验要点
对嵌套数组中的角色字段，应逐项验证：roles 作为数组、roles.* 为 in 的允许值，从而避免非法角色进入系统。
$rules = ['users' => 'required|array','users.*.roles' => 'required|array|min:1','users.*.roles.*' => 'in:admin,editor,viewer',
];5. 结合邮箱与角色的完整示例
完整示例数据结构
一个典型的请求载荷包含一个名为 users 的数组，每个元素含有 email 与 roles 两个字段。通过结构化数据可以实现一站式校验，便于后端统一处理。
示例数据如下所示：多条用户信息将在一次请求中提交，每条都要通过邮箱与角色的校验。
完整规则定义
将邮箱与角色的规则合并在同一个验证对象中，可以获得统一的校验逻辑与错误信息。下面的规则覆盖了邮箱、角色及嵌套结构。
$rules = ['users' => 'required|array','users.*.email' => 'required|email','users.*.roles' => 'required|array|min:1','users.*.roles.*' => 'in:admin,editor,viewer',
];6. 使用 Form Request 提高维护性
创建 StoreUsersRequest
将上述规则封装到一个专用于创建的 Form Request 中，可以将控制器的逻辑与校验解耦，提升可维护性和测试性。推荐在大型项目中广泛使用 Form Request。
通过自定义消息和授权方法，可以进一步细化错误响应和权限控制。Form Request 提供了规则、消息与授权的集中管理。
// App/Http/Requests/StoreUsersRequest.php
namespace App\Http\Requests;use Illuminate\Foundation\Http\FormRequest;class StoreUsersRequest extends FormRequest
{public function authorize(){return true; // 根据实际权限调整}public function rules(){return ['users' => 'required|array','users.*.email' => 'required|email','users.*.roles' => 'required|array|min:1','users.*.roles.*' => 'in:admin,editor,viewer',];}public function messages(){return ['users.*.email.required' => '每个用户都需要提供邮箱。','users.*.email.email' => '邮箱格式不正确，请输入有效的邮箱地址。','users.*.roles.required' => '每个用户至少包含一个角色。','users.*.roles.*.in' => '角色不被允许，请选择 admin、editor 或 viewer。',];}
}在控制器中应用规则
控制器可以直接注入该请求对象，框架会在进入方法前完成验证并将数据注入控制器方法参数中。这使控制器关注点更清晰。
use App\Http\Requests\StoreUsersRequest;public function store(StoreUsersRequest $request)
{$validated = $request->validated();// 业务逻辑：批量创建用户等
}7. 调试与错误信息优化
常见错误信息解读
常见问题包括 邮箱字段缺失、邮箱格式错误、角色数组为空、角色不在允许集合内等。在调试阶段，查看完整的验证错误数组能快速定位问题字段。
嵌套字段的错误键可能比较复杂，通过把错误信息映射到前端字段名，可以帮助前端友好地提示用户。
自定义错误信息示例
为嵌套字段提供清晰的错误文案，可以提升用户体验。在 Messages 中自定义覆盖默认信息。
$messages = ['users.*.email.required' => '请输入每位成员的邮箱。','users.*.email.email' => '邮箱格式无效，请检查邮箱地址。','users.*.roles.*' => '请选择有效的角色（admin, editor, viewer）。',
];