不能直接用delete实现回收站，因为delete是物理删除且不可逆；必须用update改deleted_at字段实现软删除，所有查询、join、统计均需过滤deleted_at is null，并定期物理清理过期数据。
为什么不能直接用 DELETE 实现回收站
因为 DELETE 是物理删除，执行后数据从磁盘移除（或标记为可覆盖），无法按需恢复。回收站本质是「延迟物理删除」，必须把删除动作转为状态变更 + 时间戳记录。
常见错误现象：DELETE FROM user WHERE id = 123 执行完就再也查不到这条记录，连快照都救不回来；或者靠备份还原，但耗时且影响全表。
正确思路：所有“删除”操作统一走 UPDATE，只改一个字段，比如 is_deleted 或 deleted_at。
用 deleted_at 字段实现软删除 + 恢复
比布尔型 is_deleted 更灵活——能区分删除时间、支持按时间范围清理、兼容唯一约束（如邮箱未被删时仍需唯一）。
实操建议：
- 建表时加
deleted_at TIMESTAMP NULL字段，**不要设默认值**（否则新插入记录就“已删除”） - 查询时统一加条件：
WHERE deleted_at IS NULL，建议封装成视图或 ORM scope - 删除操作写成：
UPDATE user SET deleted_at = NOW() WHERE id = 123 - 恢复操作就是：
UPDATE user SET deleted_at = NULL WHERE id = 123 - 注意索引：给
deleted_at加索引，否则带IS NULL的查询可能全表扫描
真实业务中容易漏掉的 JOIN 和统计场景
一旦引入软删除，所有关联查询和聚合都得同步过滤，否则会把“已删数据”算进去，导致数量对不上、页面展示异常。
常见错误现象：订单列表页显示“共 120 笔”，点进去只有 115 条；后台统计日活用户数虚高。
实操建议：
-
JOIN时必须显式加条件：LEFT JOIN order o ON u.id = o.user_id AND o.deleted_at IS NULL - 统计类 SQL 别偷懒写
COUNT(*)，要写COUNT(CASE WHEN deleted_at IS NULL THEN 1 END)或先过滤再计数 - 如果用视图封装基础查询逻辑，记得在视图里固定写死
WHERE deleted_at IS NULL，避免下游误用 - ORM 如 Laravel Eloquent 默认支持全局作用域，但 Django 的
QuerySet需手动重写get_queryset()，别依赖文档没写的“自动行为”
什么时候该清空回收站（物理删除）
软删除不是永久存档，长期堆积会拖慢查询、膨胀表体积、干扰备份与主从同步。
实操建议：
- 设定保留策略：比如
deleted_at 的才允许物理删除 - 用定时任务（如 cron +
DELETE FROM user WHERE deleted_at ）批量清理，**别在应用层遍历再删** - 物理删除前务必再查一次：
SELECT * FROM user WHERE deleted_at ，确认删的是真回收站数据，不是误标 - 注意外键：如果其他表有
ON DELETE CASCADE，软删除时这些关联行不会被级联，得自己用触发器或应用层处理；物理删除时则会触发，要提前评估影响
回收站机制的核心不是“多加个字段”，而是所有读写路径都得重新对齐这个状态。最容易被忽略的是那些写在角落里的报表 SQL、导出脚本、数据分析临时查询——它们往往绕过主逻辑，一删就错。
