ThinkPHP怎么处理模型字段条件批量软删_ThinkPHP按筛选条件删除多条记录【操作】

ThinkPHP 软删失效？别急着改代码，先看配置字段类型是不是对的。模型必须启用 SoftDelete，delete_time 选 int 或 datetime；批量软删用 destroy() 而不是 delete()；查已删记录用 withTrashed()；恢复数据用 restore() 但得留意业务一致性。

ThinkPHP 软删字段没生效？先确认 soft_delete 配置和字段类型

很多人以为调了 delete() 就自动软删了，结果数据库记录要么直接没了，要么纹丝不动。原因多半是模型压根没识别到 delete_time 字段。你要做的是：

• 模型里必须加上 use SoftDelete; 并且显式声明 protected $deleteTime = 'delete_time'; —— 字段名和数据库得完全一致。
• delete_time 的类型推荐 int(10) UNSIGNED 或 datetime，别用 varchar，否则 where('delete_time', null) 这类条件永远匹配不上。
• 如果用了自定义字段（比如 is_deleted），还得额外配 protected $defaultSoftDelete = 1; 和 protected $softDelete = true;，不然框架不知道拿哪个值做默认标记。

批量软删必须用 destroy()，别用 delete()

这是个非常容易踩的坑：delete() 即使在开启了软删的模型上，也是物理删除。真正的批量软删方法其实是 destroy()，它只会把符合条件的记录打上删除标记，而不是删数据行。

• 正确写法：UserModel::destroy(['status' => 0, 'id' => ['in', [1,2,3]]]);
• 错误写法：UserModel::where(['status' => 0])->delete(); —— 这会直接走 SQL DELETE，绕开软删逻辑。
• destroy() 默认按主键逐条软删，如果想跳过主键校验、直接执行 UPDATE 语句，可以加第二个参数：destroy($where, true)，第二个参数为 true 表示强制批量更新。

按条件软删后查不到数据？检查全局作用域是否干扰

软删后默认查不到已删记录，这是通过全局作用域自动添加 where('delete_time', null) 实现的。但如果你手动写了同样的条件，或者用了 withTrashed() / onlyTrashed()，行为就会发生变化。

• 想查包括已软删的记录：UserModel::withTrashed()->select();
• 只查已软删的记录：UserModel::onlyTrashed()->select();
• 如果模型里重写了 baseScope() 或定义了自定义 scope，可能会覆盖掉软删的全局作用域，导致条件失效。
• 调试时可以打印 SQL 查看：echo UserModel::where(['id' => 1])->buildSql();，检查生成的 WHERE 子句里是否包含 delete_time IS NULL。

软删后恢复数据用 restore()，但注意主键约束和关联逻辑

restore() 其实只做一件事：把 delete_time 字段清空。其他字段原样不动。如果你的业务依赖软删前的状态（比如缓存、关联表状态），那恢复后也得自己补逻辑。

• 单条恢复：UserModel::withTrashed()->find(123)->restore();
• 批量恢复：UserModel::withTrashed()->where('delete_time', '', null)->restore();
• 如果模型字段有唯一索引（比如 email），恢复时得确认那条记录的值没有被新数据占用，否则会抛出 Integrity constraint violation 异常。
• 关联模型不会自动恢复。比如订单被软删了，即使你把用户恢复了，订单仍然不可见——需要单独处理。

软删看起来只是改个字段，但字段类型、方法选择、作用域叠加、恢复时的业务一致性，每个环节都容易漏掉一两个细节。尤其是在批量操作里，destroy() 和 delete() 的差别，几乎决定了你是删数据还是删日志。