confirmed规则仅适用于含同名_confirmation后缀字段的敏感值校验，如password/password_confirmation，要求两字段同时存在且字符串完全相等，不处理空格、大小写，不支持数组或嵌套结构。
confirmed 验证只适用于需要“二次确认”的字段，比如密码、邮箱、手机号等敏感值，且必须配套存在 xxx_confirmation 字段才能生效。
confirmed 规则的硬性前提条件
它不是通用校验，而是强依赖命名约定和表单结构：
-
confirmed会自动查找同名 +_confirmation后缀的字段（如password→ 查找password_confirmation） - 两个字段都必须出现在请求中，缺一不可；否则直接报
The password confirmation does not match. - 仅比对字符串值是否完全相等，不处理空格裁剪、大小写转换等逻辑
- 不适用于数组字段（如
roles[]），因为 Laravel 不会自动匹配roles_confirmation[]这类结构
适合用 confirmed 的典型表单场景
以下情况可以直接放心用，其他场景建议改用自定义规则：
- 用户注册页：
password+password_confirmation（最常见） - 重置密码页：同样使用
password和password_confirmation字段 - 管理员设置新邮箱时：用
email+email_confirmation（需注意邮箱格式仍要单独加email规则） - 支付确认页输入新银行卡号：用
card_number+card_number_confirmation（但要注意前端是否允许明文传输）
为什么不能随便套在任意字段上？
几个容易踩坑的实际表现：
- 表单用了
name="new_password"，但规则写成'password' => 'confirmed'→ 找不到password_confirmation，验证失败 - 前端把确认字段命名为
confirm_password而非password_confirmation→confirmed完全不触发，静默跳过 - API 请求里漏传
password_confirmation，哪怕只传了password→ 返回 422 错误，但错误信息是The password confirmation field is required.，容易误导排查方向 - 字段是布尔类型或整数（如
is_active），加confirmed没意义，Laravel 会把它转成字符串比对，结果不可控
替代方案：什么时候该放弃 confirmed？
当需求超出它的能力边界时，别硬套：
- 需要忽略大小写比对（如邮箱确认）→ 改用
same:email+ 在prepareForValidation()中统一 strtolower - 要同时校验多个字段组合（如密码+安全问题答案）→ 自定义
ValidatePasswordAndSecurityAnswer规则 - 确认字段不在同一请求层级（比如嵌套在
data.attributes里）→confirmed找不到，必须手写required_with+same - 前端用 JSON 提交，确认字段名带点号（
user.password_confirmation）→confirmed不支持路径语法，会失效
真正麻烦的从来不是规则本身，而是前端字段命名和后端规则名不一致——这点在多人协作或前后端分离项目里最容易被忽略。
