thinkphp软删除后unique验证冲突的直接原因是验证器默认查询包含已软删记录，导致误判；解决方式是让unique规则显式添加delete_time=null条件，或修改验证器逻辑只查未删除数据。
ThinkPHP软删除后插入同字段数据报unique冲突
直接原因是验证器的 unique 规则默认不感知软删除字段，查库时把已软删记录也纳入比对范围，导致“邮箱已被占用”误判。这不是数据库层面的错误，而是验证逻辑和业务意图错位。
解决方式不是改数据库索引，而是让验证器只查未删除数据：
- 验证规则必须显式排除软删除记录，写法是
['unique' => 'user,email,delete_time,NULL']（TP 6.1+ 支持第四参数传 where 条件） - 旧版本 TP 或自定义验证场景，需重写
unique方法，在查询前加->whereNull('delete_time') - 若用模型
validate(true)，确保验证器类中scene对应的规则已更新，否则场景切换会漏掉该条件
MySQL唯一索引如何兼容软删除（含delete_time字段）
数据库层唯一性必须靠索引保障，不能只依赖 PHP 层验证。TP 的 delete_time 字段默认值为 NULL，这恰好可被 MySQL 唯一索引利用——NULL 不参与重复校验。
正确做法是建联合唯一索引：
- 迁移中执行：
Schema::table('user', function (Blueprint $table) { $table->unique(['email', 'delete_time']); }); - 已有表先删原
email单列唯一索引，再建新联合索引，否则建索引失败 - 注意：该方案在 SQLite 下无效（SQLite 把
NULL当作相等值），开发环境用 MySQL 才能准确模拟
restore() 时触发唯一索引冲突怎么办
当一条记录 A 被软删除后，另一条记录 B 以相同 email 插入成功，此时调用 $a->restore() 必然报 SQLSTATE[23000]: Integrity constraint violation: 1062。这是联合索引生效的正常表现，不是框架 bug。
必须在 restore 前手动检查：
- 查是否存在「未删除且 email 相同、ID 不同」的记录：
User::where('email', $a->email)->whereNotNull('delete_time')->where('id', '', $a->id)->exists() - 有冲突时，业务上要明确策略：抛异常提示用户，或先
$b->delete()再$a->restore() - TP 没有内置的
restoreOrFail()，这个预检逻辑必须自己写，且建议包在事务里
关联模型软删除与唯一索引的联动陷阱
主模型启用软删除，不会自动影响关联模型的查询行为。比如 User::withTrashed()->with('profile') 中，profile 仍按默认规则过滤（即忽略已软删的 profile 记录）。
若 profile 表也有 delete_time 字段并启用了 SoftDelete trait，还需两步：
- 在关联定义里加
->withTrashed()：return $this->hasOne(Profile::class)->withTrashed(); - Profile 模型的
unique验证（如手机号）同样要加delete_time=NULL条件，否则编辑用户资料时可能因已删 profile 占用号码而失败
最容易被忽略的是：子模型没启用 SoftDelete trait 时，withTrashed() 完全无效，也不会报错，查出来的关联数据永远是“活着的”，但数据库里其实存在已删记录——这种静默不一致会埋下线上隐患。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
