ThinkPHP怎样配置软删除功能_软删除功能配置方法【数据】
ThinkPHP软删除失效?别慌,问题通常出在这三个环节的“错位”上

免费影视、动漫、音乐、游戏、小说资源长期稳定更新! 👉 点此立即查看 👈
在ThinkPHP项目里,如果你明明启用了软删除,却发现数据还是被物理删除了,或者查询时总也过滤不掉那些“已删除”的记录,先别急着怀疑框架。这种情况,十有八九是模型配置、数据库字段和操作方式这三者没有严丝合缝地对齐。下面,我们就来一步步拆解,确保你的软删除功能坚如磐石。
一、数据库添加软删除字段
软删除功能的基石,是一个可以为空的时间标记字段。这个字段必须实实在在地躺在你的数据表里,而且类型要和框架预期的保持一致。默认情况下,这个字段名叫delete_time,在MySQL里,通常设置为DATETIME或TIMESTAMP类型,并且允许为NULL。
首先,执行SQL语句添加字段:ALTER TABLE user ADD delete_time DATETIME NULL DEFAULT NULL;
其次,如果你在使用迁移文件管理数据库结构,需要注意:ThinkPHP 6.x并不原生支持Lara vel风格的$table->softDeletes()写法。这个提示是为了兼容性考量,实际操作中,你还是得老老实实手写字段定义。
立即学习“PHP免费学习笔记(深入)”;
最后,也是很容易被忽略的一步:对已有表结构进行修改后,务必记得清空runtime/cache/目录。否则,模型可能还在使用缓存中的旧表结构,导致软删除逻辑根本不起作用。
二、模型类启用SoftDelete trait并声明配置
光在数据库加字段还不够,模型层也得同步“开机”。仅仅引入trait并不足以激活软删除,你必须在模型中显式启用它,同时还要留意别让它和自动时间戳功能“打架”。框架是通过trait注入行为来实现的,而不是一个全局开关。
第一步,在模型文件的顶部导入必要的命名空间:use think\model\concern\SoftDelete;
第二步,在模型类的定义中,声明使用这个trait,并设置启用标志:use SoftDelete; protected $useSoftDelete = true;
第三步,如果你的软删除字段不是默认的delete_time,比如用了deleted_at,那就需要特别指定:protected $deleteTime = 'deleted_at';
第四步,尤其要小心:如果模型同时启用了自动时间戳(即设置了$autoWriteTimestamp = true),千万别把delete_time字段错误地列入$createTime或$updateTime的配置中。否则,新记录一插入,这个字段就被写入了时间,造成“刚出生就被标记为删除”的尴尬局面。
三、验证字段类型与模型类型声明一致性
这一步是很多隐蔽问题的根源。数据库字段的类型,必须和模型中的类型声明完全匹配。如果这里对不上,框架内部进行条件比对(比如whereNotNull('delete_time'))时就会失败,导致软删除彻底失效。
情况一:如果数据库字段就是DATETIME类型,那么模型里保持默认即可,无需额外声明。
情况二:如果字段用的是BIGINT类型来存储时间戳整数,那么必须在模型中明确添加类型映射:protected $type = ['delete_time' => 'integer'];
情况三:绝对要避免将字段设置为NOT NULL DEFAULT CURRENT_TIMESTAMP。这样一来,所有新插入的记录,delete_time字段都会有一个默认值,会被框架误判为已删除状态,查询时根本找不到“正常”数据。
四、确保删除操作走模型方法而非Db类
这是一个关键性原则:软删除的逻辑只在模型层生效,Db类的操作会完全绕过这个机制,直接执行物理删除。所以,所有删除动作,都必须通过模型实例或模型的静态方法来触发。
来看看正确和错误的示范:
正确方式(触发软删除):$user = User::find(123); $user->delete();
正确方式(批量软删除):User::destroy([101, 102, 103]);
错误方式(导致真删):Db::name('user')->where('id', 123)->delete();
错误方式(忽略模型逻辑):User::where('id', 123)->delete(); (注意,这里虽然用了模型名,但调用的是查询构造器的delete方法,依然不会触发软删除)
五、配置查询默认行为与显式解除过滤
软删除一旦启用,就会改变模型的默认查询行为。所有通过模型进行的查询(比如select、find),都会自动加上WHERE delete_time IS NULL这个条件,帮你过滤掉已删除的数据。如果你想查看这些数据,就必须主动干预查询链。
第一,查询全部数据(包括已软删除的):User::withTrashed()->select();
第二,只查询已被软删除的数据(类似回收站功能):User::onlyTrashed()->select();
第三,如果你想恢复某条记录,必须先把它从“回收站”里找出来:$user = User::onlyTrashed()->find(123); if ($user) $user->restore();
最后提醒一下:withTrashed()和onlyTrashed()这两个方法,必须在select()或find()等最终查询方法之前调用,否则不会生效。而且,它们只影响当前这一次查询,并不会改变模型的默认行为。
游乐网为非赢利性网站,所展示的游戏/软件/文章内容均来自于互联网或第三方用户上传分享,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系youleyoucom@outlook.com。
同类文章
Debian环境下Node.js日志清理技巧有哪些
Debian服务器Node js日志管理与轮转最佳实践指南 高效的日志管理是保障Node js应用稳定运行与快速排障的关键环节。在Debian服务器环境中,随着应用持续运行,日志文件会不断累积,若不加以妥善管理,极易导致磁盘空间耗尽,进而引发服务中断。本文将深入解析几种在Debian系统上管理Nod
Debian JS日志如何自动化处理
Debian JS日志自动化处理方案 处理服务器日志,尤其是Node js应用产生的日志,如果全靠手动,那简直就是运维人员的噩梦。文件无限增长、问题难以追溯、磁盘空间告急……这些问题,其实一套清晰的自动化方案就能搞定。下面就来聊聊如何在Debian系统上,为你的JS应用搭建一个从生成、轮转、采集到分
Debian JS日志如何审计
Debian JS日志审计实操指南 一 审计目标与总体架构 要搭建一套有效的日志审计体系,首先得把目标和框架理清楚。这事儿其实不复杂,核心就三件事:明确范围、打通链路、保障安全。 明确审计范围:一个完整的JS应用生态,日志来源是分散的。前端浏览器的JS异常、后端的Node js服务日志、承载服务的W
Debian JS日志如何分析性能瓶颈
Debian 环境下用 JS 日志定位性能瓶颈的实操指南 性能问题就像系统里的“暗伤”,平时不易察觉,一旦爆发却足以让应用瘫痪。好在,高质量的日志就是最好的“诊断报告”。今天,我们就来聊聊在 Debian 环境中,如何从海量 JS 日志里,精准揪出那些拖慢系统的“元凶”。 一 准备可度量的日志 定位
Debian JS日志如何监控
Debian 上监控 Ja vaScript 日志的实用方案 一 场景与总体架构 聊到Ja vaScript日志监控,首先得把场景分清楚。前端和后端,完全是两码事。 前端 JS(浏览器)这块,核心是捕捉运行时的错误和用户行为。通常的做法是接入像 Sentry 这类专业的前端异常监控服务。当然,开发阶
- 日榜
- 周榜
- 月榜
1
2
3
4
5
6
7
8
9
10
相关攻略
2015-03-10 11:25
2015-03-10 11:05
2021-08-04 13:30
2015-03-10 11:22
2015-03-10 12:39
2022-05-16 18:57
2025-05-23 13:43
2025-05-23 14:01
热门教程
- 游戏攻略
- 安卓教程
- 苹果教程
- 电脑教程
热门话题

