发布于2026-07-06 阅读(0)
扫一扫,手机访问
ThinkPHP5 的软删除,说起来不算复杂,但实际用起来,总有人栽跟头。不是加个字段、改个配置就能糊弄过去——必须得模型引入、字段定义、调用方式这三样东西严丝合缝地对上,不然 delete() 或者 destroy() 一下去,数据库里就真没了,想查都找不着原因。

先说模型部分,怎么把 SoftDelete 这个能力正确装进去。
这个问题坑过不少人——看着是引入了,实际上没生效。关键点其实就三个,一个都不能省:
use traits\model\SoftDelete; 这句必须写在类的最顶上。注意路径,是 traits\model\SoftDelete,别顺手写成 TP6 的 think\model\concern\SoftDelete,那东西不通用。use SoftDelete;。光在顶部导入命名空间,不等于这个 trait 就自动用上了,这点很容易忽略。delete_time,比如叫 is_deleted 或者 deleted_at,那就得在模型里声明一下:protected $deleteTime = 'is_deleted';,不然框架找不到。$defaultSoftDelete 属性,只在用整型标记(比如 0/1 这种)时才需要配置,而且值必须是 0。如果你用的是时间戳类型,这个属性就别动它,设了反而可能出问题。接下来是数据库字段,这个环节最容易出问题,而且问题往往藏在表面底下。
这是静默失败的高发区。字段类型或者 NULL 约束不对,delete() 执行完看着像成功了,实际上时间没写进去,也没报任何错,数据就这么“消失”了。
DATETIME 或者 TIMESTAMP,而且必须允许为 NULL。千万别加 DEFAULT CURRENT_TIMESTAMP——不然新记录一插入,delete_time 就被填上了值,系统会误以为这条数据已经被删过了。BIGINT 存时间戳(比如 delete_time BIGINT UNSIGNED NULL),那模型里一定要配一个类型转换:protected $type = ['delete_time' => 'integer'];。否则写入的时候会被转成字符串,再强转回整数,结果往往变成 0。NOT NULL。就算你给了默认值 0 或者 NULL,在 MySQL 8.0 以上的版本里,约束检查更严格,软删逻辑仍然可能被跳过。说完了字段和模型,调用方式才是真正的核心——很多问题都出在这里。
关键要搞清楚:软删除是模型层的功能,不是数据库层的能力。一旦你写了 where(),就等于脱离了模型上下文,进入了 Db 类的执行流程,那就不归 soft delete 管了。
UserModel::where('id', 1)->delete() 这样写是错的。它本质上相当于 Db::name('user')->where(...)->delete(),把模型逻辑完全绕过去了。$user->delete(),要么用静态方法 UserModel::destroy(1)。destroy() 支持批量操作,比如 UserModel::destroy([1,2,3]) 或者 UserModel::destroy('1,2,3'),也支持闭包条件,但底层走的一直是模型逻辑。true:UserModel::destroy(1, true) 或者 $user->delete(true),不然默认就是软删。软删之后怎么查、怎么恢复,也是一个容易踩坑的地方。
默认情况下,查询会自动过滤掉已经被软删的记录。但如果你想查回收站或者恢复数据,操作很容易写错,而且错了也不报异常。
UserModel::withTrashed()->find(1)。注意,withTrashed(true) 是旧写法,TP5.1.9 版本之后就不支持布尔参数了。UserModel::onlyTrashed()->find(1)。这一步返回的就是那些处于“已删除”状态的记录。$user->restore()。如果写成 UserModel::where(...)->restore(),会直接报 Call to undefined method 的错误。$user = UserModel::onlyTrashed()->find(1); if ($user) $user->restore(); 这样才行。否则就算调了 restore(),它也只是静默返回 false,什么都不做。说到底,最容易被忽略的,是字段约束和调用路径之间的耦合关系。就算模型和字段都配对了,只要控制器里写了 Db::name('user')->where(...)->delete(),软删就彻底失效。这不是什么 bug,而是 ThinkPHP 的设计原则——软删的能力,被严格绑定在模型实例的生命周期里。