ThinkPHP 6.x 的 unique 规则不支持多字段联合校验，仅适用于单字段全局唯一；必须通过数据库联合索引 + Rule::callback 自定义验证实现安全的联合唯一校验。
ThinkPHP 的 unique 规则不支持多字段联合校验
直接说结论：unique 验证规则在 ThinkPHP 6.x（包括 6.0/6.1/6.2）中只接受单字段 + 单表 + 单条件，无法原生写成 unique:users,username,email 这种形式。你如果这么写，框架会报错或静默失效。
常见错误现象是：提交两个字段都重复的数据，验证却通过；或者抛出 Call to undefined method think\db\Query::field() 类似异常——本质是底层把多字段当成了字段名传给查询构造器。
- 唯一性校验必须落到数据库层（建联合索引）+ 应用层（自定义验证逻辑）双保险
- 不能只依赖模型的
validate或控制器里写个->where(['username'=>$u,'email'=>$e])->count()就完事——漏掉并发场景 - ThinkPHP 自带的
unique仅适用于「单字段全局唯一」，比如手机号、邮箱本身独立唯一
建联合索引是硬性前提，否则验证无意义
即使你在 PHP 层写死了查两条字段，没有数据库索引，高并发下照样可能插入重复数据。MySQL 的 INSERT ... ON DUPLICATE KEY UPDATE 或事务里的 SELECT ... FOR UPDATE 都依赖索引加锁。
执行这条 SQL（以 MySQL 为例）：
立即学习“PHP免费学习笔记（深入）”；
ALTER TABLE `users` ADD UNIQUE INDEX `uniq_username_email` (`username`, `email`);
注意点：
- 字段顺序影响索引生效范围：
(username,email)能加速WHERE username=? AND email=?，但对WHERE email=?无效 - 如果字段允许 NULL，MySQL 8.0+ 会把多个
NULL视为不同值，导致“看似重复却能插入”——建议字段设为NOT NULL - 索引名别用中文或特殊符号，ThinkPHP 某些版本解析迁移文件时会卡在非法字符上
用 Rule::callback() 写安全的联合唯一验证
ThinkPHP 6.1+ 支持闭包验证规则，比手动在控制器里查更可控、可复用。它会在验证流程中执行，且和其它规则共享事务上下文（如果你开了事务）。
示例（在模型的 rule 定义里）：
use think\Validate;
// ...
protected $rule = [
'username' => 'require|alphaNum',
'email' => 'require|email',
['username', 'email'] => Rule::callback(function ($value, $rule, $data) {
$count = $this->where(['username' => $data['username'], 'email' => $data['email']])->count();
return $count === 0;
}, '用户名和邮箱组合已存在'),
];
关键细节：
-
$this是当前模型实例，自动绑定表名和连接，不用写Db::name('users') - 闭包里用
$data取全部输入，避免只拿$value（那是当前字段值，不是联合条件） - 不要在闭包里 throw 异常，必须 return bool —— 否则验证中断且不报错信息
- 如果模型有软删除，记得加
->withoutTrashed()，否则已删除记录仍会拦住新数据
更新时要排除自身 ID，否则编辑总会提示重复
新增时查不到是正常，但编辑用户资料时，where 条件没排除当前记录 ID，就会把自己查出来，永远验证失败。
改法很简单：在闭包里判断是否在更新，并动态加 id 排除：
['username', 'email'] => Rule::callback(function ($value, $rule, $data) {
$query = $this->where(['username' => $data['username'], 'email' => $data['email']]);
if (!empty($data['id'])) {
$query->where('id', '<>', $data['id']);
}
return $query->count() === 0;
}, '用户名和邮箱组合已存在'),
这里容易踩的坑：
-
$data['id']可能是字符串，用比!=更稳妥（PDO 自动类型转换有时不一致） - 如果主键不是
id（比如叫user_id），得同步改条件字段名，where不会自动识别主键别名 - 批量更新（
saveAll）场景下，这个写法不适用，得换到业务逻辑层单独处理
联合唯一这事，索引是地基，验证是门锁，少哪样都拦不住脏数据。最麻烦的其实是字段顺序和 NULL 值处理，线上出过问题的几乎全是这两点没对齐。
