ThinkPHP删除数据怎么拦截_ThinkPHP删除前事件指南【操作】

在ThinkPHP开发中，很多人都会遇到一个困惑——明明写了Model::beforeDelete()事件监听，结果发现它根本不执行。这种时候，十有八九是“跑错门了”。

Model::beforeDelete() 为什么经常不触发

一句话捅破窗户纸：Db::delete() 是直接走数据库查询的，完全绕过了模型层，自然也就不会触发任何事件钩子。只有通过模型实例发起的删除，比如 Model::get()->delete() 或 Model::destroy()，beforeDelete 才会被调用。

不少人踩过的坑是：费心写了 beforeDelete 逻辑，结果在定时清理任务里偷懒用了 Db::name('log')->where(...)->delete()，最后这个函数压根儿没被系统“翻牌”。

那满足什么条件才能触发呢？很简单，必须是“模型实例”自己发起的删除才作数。比如下面这几种情况：

• User::get(123)->delete() ✅ 触发
• User::destroy(123) ✅ 触发（但注意，它会连带触发验证、关联处理和事件）
• Db::name('user')->where('id', 123)->delete() ❌ 不触发

如果你的业务非要拦截删除（比如记录操作人、校验权限），那么就应该老老实实走模型方式，并且要确保 $pk 主键设置正确、没有被意外覆盖，否则模型也找不到那条数据。

Db::delete() 和 Model::destroy() 删除行为差异

虽然都带个“删”字，但底层干的活完全不同。

• Db::delete()：简单粗暴，直接拼 SQL 执行 DELETE FROM ... WHERE ...。它不搞事务包装、不触发事件、不做数据验证、不加载模型、不走关联逻辑。唯一的优点就是——快，且可控。
• Model::destroy()：动作就多了。它先查出记录（生成模型实例），然后逐条调用 beforeDelete → 验证 → 处理关联 → 触发 afterDelete → 最后才真正删掉。要是一口气删 1000 条，它就可能生成 1000 个模型实例外加 N 次关联查询，内存溢出或锁表的风险很高。

一个经典的翻车现场：有人用 UserLog::destroy(['status' => 'expired']) 去清日志表，50 万行数据直接让程序卡死或超时。换成 Db::name('user_log')->where('status', 'expired')->limit(1000)->delete() 分批处理，稳得多。

软删除字段为 delete_time 时，delete() 为何返回 0 却不报错

这个现象挺迷惑人，但原理其实很简单：不是删除失败，而是被“软删除机制”给截胡了。

只要模型用了 use SoftDelete 特性，你对它发起的任何 ->delete() 调用，都会被默认“翻译”成一次 UPDATE 操作——把 delete_time 字段设置为当前时间戳。所以你看实际执行的 SQL 会是 UPDATE ... SET delete_time = ...，影响行数虽然显示为 1，但业务上你预计的“DELETE”行为并没有发生。

要强制物理删除，必须显式关闭软删除：

User::withoutSoftDelete()->where('id', 123)->delete();

或者直接用 Db 类，它根本不认你的软删除配置。需要特别说明的是，destroy() 方法同样受软删除影响，想硬删也得加上 withoutSoftDelete()。

清理任务中加锁和分页为什么不能省

聊到定时清理任务，真正考验人的不是“怎么删”，而是“删一半怎么办”“删重了怎么防”。

定时脚本不加锁，一旦多实例同时跑起来，就会导致双删甚至多删。更严重的，如果不做分页，单次 DELETE 干掉几万行，MySQL 的写锁会死死挂住，其他读写请求全被堵死，DBA 的电话马上就到。

所以，正确的做法是：

• 用文件锁兜底：file_put_contents(RUNTIME_PATH . 'clean_user_log.lock', time(), LOCK_EX)，清理完毕后再 unlink() 解锁。
• 每次最多处理 1000 行：Db::name('user_log')->where('created_at', '<', $cutoff)->limit(1000)->delete()。
• 删除后立即检查影响行数：if ($affected === 0) break;，防止条件失效后无限循环。
• 不要包在 transaction 里：DELETE 本身是原子操作，再加事务反而会延长锁的持有时间，得不偿失。

真正能让你睡安稳的，从来不是某个模型事件或 try-catch，而是锁、分片和行数判断这套组合拳。