Rule::exists() 是验证邮箱是否已存在的最直接方法，支持条件排除、自动参数绑定和安全查询；复杂场景可封装为可调用规则类；务必配合数据库唯一索引与小写归一化确保最终一致性。
验证邮箱是否已存在：用 Rule::exists() 最直接
不需要写完整类，Laravel 自带的 Rule::exists() 就能搞定「邮箱是否已存在于系统中」这个需求。它本质是查数据库，比手写闭包或自定义类更安全、更易读，也自动处理了转义和绑定参数。
常见错误是直接拼 SQL 字符串，比如 'email' => 'required|email|unique:users,email' —— 这只能防「新增时重复」，无法用于「编辑时跳过自己」；而 Rule::exists() 天然支持条件排除，适合登录前校验、注册预检等场景。
- 基础用法：
['email' => ['required', 'email', Rule::exists('users', 'email')]] - 排除当前用户（如编辑资料）：
Rule::exists('users', 'email')->whereNot('id', $user->id) - 加额外条件（如只查激活用户）：
Rule::exists('users', 'email')->where('status', 'active')
需要复用逻辑？写一个 Invokable 验证对象更清晰
当校验逻辑变复杂（比如要查多个表、加缓存、或统一走 API 接口），或者多个地方都要用同一套邮箱存在性判断时，才值得封装成类。推荐用可调用对象（__invoke），而不是继承 Validator 或写静态方法。
它比闭包更易测试、可注入依赖（如 UserRepository），且 Laravel 会自动解析构造函数参数。
- 创建类：
php artisan make:rule EmailExistsInSystem - 在
__invoke方法里写查询逻辑，返回true表示通过，false表示失败 - 使用时直接传实例：
['email' => [new EmailExistsInSystem()]] - 别忘了在
passes()里处理空值或 null 邮箱，否则可能抛出TypeError
validateWithBag 和自定义错误消息怎么配
用 Rule::exists() 或自定义规则时，如果想把错误归到特定错误包（比如前端弹窗只显示 login_errors），不能只靠 validate()，得用 validateWithBag()。
默认错误消息是 “The :attribute is not exists.”，太生硬。建议在 resources/lang/zh-CN/validation.php 里加一条：
"exists" => "该 :attribute 在系统中不存在，请确认输入是否正确。"
或者临时覆盖：Rule::exists('users', 'email')->message('邮箱未注册，请先注册账号')。
- 错误包名必须和 Blade 中
$errors->login_errors的键完全一致 -
message()只对当前规则生效；全局改用语言文件更稳妥 - 别在消息里写“请重试”“请联系管理员”这类无信息量提示——用户真正需要的是明确失败原因
注意 MySQL 大小写和唯一索引的实际行为
Laravel 的 exists 规则底层走的是 where 查询，不依赖数据库索引类型。但如果你的邮箱字段没建 UNIQUE 索引，高并发下仍可能插入重复值——验证通过和写入之间存在竞态窗口。
更隐蔽的问题是 MySQL 默认对 utf8mb4_general_ci 排序规则不区分大小写，ABC@EXAM.COM 和 abc@example.com 会被视为相同。而 PHP 的 filter_var($email, FILTER_VALIDATE_EMAIL) 不管这个，所以光靠验证规则不够。
- 生产环境务必给
email字段加UNIQUE索引 - 考虑在模型
creating事件里统一strtolower($this->email) - 如果已有数据大小写混杂，先清洗再加索引，否则建索引会失败
规则只是第一道门，数据库约束才是最终防线。漏掉索引或忽略 collation，再严谨的 PHP 验证都白搭。
