软删除数据需手动物理清除，否则导致数据库膨胀；thinkphp中delete()默认仅标记delete_time，物理删除须传true参数或force(true)，并严格限制时间与范围。
软删除后的数据不会自动物理清除，必须手动加定时任务清理；否则数据库会持续膨胀，查询变慢，备份体积失控。
软删除数据怎么被真正删掉
ThinkPHP 的 delete() 默认只写 delete_time，不删行。要物理删除，得显式传 true 第二个参数，或用 force(true) ——但这个动作不能随便触发，必须加时间条件和范围控制。
-
User::destroy(123, true)：单条物理删，适合恢复后确认不要了再删 -
User::where('delete_time', 'delete(true)：批量删，但注意 WHERE 条件必须包含delete_time IS NOT NULL，否则可能误删未软删的记录 - 更安全写法：
User::onlyTrashed()->where('delete_time', 'delete(true)，先锁定软删状态再删，避免逻辑错位
定时任务里怎么写才不出错
直接在命令行脚本里跑 delete(true) 很危险：没锁、没日志、没兜底，服务器重启或并发调度时容易重复执行或漏执行。
- 加文件锁：
file_put_contents(RUNTIME_PATH . 'soft_delete_purge.lock', time(), LOCK_EX)，执行完unlink() - 查前先确认字段值合法：
->whereNotNull('delete_time')必须显式加上，防止因字段类型错误（如 varchar）导致条件失效 - 分批删，避免锁表太久：
->limit(1000)->delete(true)，配合 while 循环直到无返回 - 记录日志：
trace('purge_soft_deleted', "deleted {$count} users before 2025-01-01")，别只靠 echo
为什么 delete(true) 有时没反应
常见静默失败不是代码写错，而是底层约束或配置卡住：
-
delete_time字段设为NOT NULL DEFAULT CURRENT_TIMESTAMP：新插入时就有值，onlyTrashed()查不到，delete(true)就没目标可删 - 模型里启用了
$autoWriteTimestamp = true，又把delete_time写进$updateTime：更新时自动重写该字段，导致“刚删完就又被改时间”，条件永远对不上 - 事务未提交或中间件拦截了 SQL：开启
log_sql配置，看日志里实际执行的 DELETE 语句是否带WHERE delete_time IS NOT NULL
最易被忽略的一点：软删除字段名若不是 delete_time（比如叫 is_deleted），那定时任务里所有 where 和 onlyTrashed() 都得同步改，否则查不到、删不掉、还看不出错。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
