ThinkPHP的unique验证规则更新时需显式排除当前记录，否则会误判重复；正确写法为unique:table,field,{id},pk_name，其中{id}需从请求数据中获取，否则应使用闭包验证确保逻辑准确。
ThinkPHP 的 unique 验证规则默认不跳过当前记录
直接写 unique:users,email 会导致更新时「自己改自己」也被判重复。这不是 bug，是设计如此——验证器不知道你正在更新哪条记录，它只查表里有没有同值。
必须显式告诉它：「这条 ID 的记录不算」。否则用户改个昵称、头像，只要邮箱没变，就会卡在验证失败。
- 更新场景下，
unique必须带主键排除参数，格式为unique:table,field,except_id,pk_name -
except_id是当前要更新的记录 ID（比如$this->id或请求里的id） -
pk_name默认是id，但如果主键叫user_id，就得写全 - 注意：
except_id是值，不是字段名；pk_name是字段名
更新时传参方式决定 unique 规则怎么写
ThinkPHP 验证规则里的参数是从当前验证数据中取的，不是硬编码。所以 except_id 要能从请求数据里拿到，否则会当成字符串字面量处理。
常见错误：写成 unique:users,email,123,id —— 这样永远排除 ID=123 的记录，和当前操作无关。
立即学习“PHP免费学习笔记（深入）”；
- 正确做法是用变量占位符：
unique:users,email,{id},id，前提是请求数据里有id字段 - 如果 ID 在 URL 路径里（如
/user/42/edit），需先合并到验证数据中：$data = array_merge($data, ['id' => $id]) - 如果用模型验证（
UserModel::validate($data)），且主键不在请求体中，建议改用闭包验证或自定义规则
闭包验证更可控，适合复杂条件
当需要动态拼接排除条件（比如软删除 + 多租户 + 主键非 id），unique 字符串规则很快就不够用。
闭包能直接访问模型、请求上下文，也更容易调试。
- 示例：
['email' => ['require', function($value, $data) { $where = ['email' => $value]; if (!empty($data['id'])) { $where['id'] = ['neq', $data['id']]; } return User::where($where)->count() === 0; }]] - 注意闭包返回
true表示验证通过，false表示失败 - 闭包里用
count()比find()稍快，但差别不大；重点是逻辑清晰、可加日志、可复用
MySQL 唯一索引和验证规则不是一回事
有人以为加了数据库 UNIQUE KEY 就不用验证了，其实不行。数据库报错是 SQLSTATE[23000]，前端看到的是「服务器错误」，没法友好提示「该邮箱已被注册」。
- 验证规则负责提前拦截、给出明确提示；数据库索引负责兜底防脏数据
- 两者都要有，但不能互相替代
- 如果验证规则漏掉排除逻辑，而数据库又有唯一索引，会出现「验证通过 → 写入失败」的尴尬情况
id，以及它是不是整型。字符串 ID（比如 UUID）或空字符串 ID 都会让 {id} 占位符失效，这时候闭包几乎是唯一稳妥的选择。 
