Laravel数据库验证方法详解

Laravel数据库验证应优先使用内置的`Rule::exists()`或`Rule::unique()`，而非手写闭包查询——前者语义清晰、自动处理软删除、支持忽略当前记录、避免N+1和验证上下文丢失，且易于测试与复用；闭包查库则易出错、难维护、不兼容异常处理与缓存，还破坏验证一致性；对于更复杂的业务逻辑（如跨表校验、动态条件计算），应封装为可实例化的自定义Rule类，并确保正确引入、传参和返回错误信息，从而让验证规则在Web、API、队列、命令行等所有场景下行为统一可靠。

直接说结论：要用 Rule::exists() 或 Rule::unique()，而不是手写闭包查数据库 —— 否则容易漏掉软删除、忽略当前记录、绕过验证上下文，甚至引发 N+1。

Rule::exists() 和 Rule::unique() 该选哪个？

看你要验证的语义：

• Rule::exists('users', 'email')：只检查数据库里「是否存在这个值」，不管是不是当前用户，也不管是否软删除（默认包含）
• Rule::unique('users', 'email')：默认做「唯一性检查」，但更新场景下必须加 ->ignore($id)，否则会把当前记录自己当冲突
• 软删除模型要排除已删除记录？Rule::unique('users', 'email')->ignore($user->id)->whereNull('deleted_at')
• 字段名不是 id？显式传第二个参数：->ignore($user->uuid, 'uuid')

为什么别在 rules() 数组里写 DB::table()->where()->exists() 闭包？

这种写法看似灵活，实则埋雷：

• 闭包规则不支持自动注入请求数据，比如想用 $request->route('id')，得手动传参，易出错
• 闭包里查数据库，不会被 Laravel 的验证器缓存或优化，可能重复执行多次
• 如果闭包里抛异常（比如 DB 连接失败），会直接崩掉整个验证流程，而不是进 $errors
• 无法复用 —— 下次在另一个 FormRequest 里还得重写一遍
• 测试困难：没法 mock 闭包里的 DB 调用

需要更复杂逻辑时，怎么安全地查数据库？

比如「用户邮箱不能和管理员邮箱相同」「价格不能超过该分类下所有商品均价的 2 倍」—— 这类规则超出 exists/unique 范围，推荐走 Rule 类：

• 用 php artisan make:rule PriceNotExceedingAverage 生成类
• 在 passes() 中写完整查询：DB::table('products')->where('category_id', $category_id)->avg('price')
• 务必在 message() 返回非空字符串，否则错误不显示
• 不要在 passes() 里 throw new Exception，Laravel 验证器只认 return false + 正确 message
• 如果需访问请求对象（如路由参数），构造函数接收 $request 并在 passes() 中使用

FormRequest 中调用自定义 Rule 类，为什么没生效？

最常见原因是没实例化：

• 错：'email' => 'required|exists:users,email'（这是字符串规则，不是你写的 Rule 类）
• 对：'email' => ['required', new EmailNotInAdminList]（必须用 new 实例化）
• 如果 Rule 类带参数，比如 new EmailNotInAdminList($exceptRole)，确保参数能稳定传入
• 注意命名空间：Rule 类默认在 App\Rules，别漏了 use App\Rules\EmailNotInAdminList;

真正麻烦的从来不是写 SQL，而是让验证逻辑在 Web 表单、API 请求、队列任务、命令行脚本中行为一致 —— 所以优先用 Rule::exists() 这类内置封装，复杂逻辑再下沉到 Rule 类，别图省事在数组里塞闭包。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~