不能只加 is_deleted 字段，因易漏过滤、污染SQL、ORM绕过；应结合视图封装、ORM全局拦截、原子化删/恢复操作及跨表一致性处理。
为什么不能只加一个 is_deleted 字段就完事
加个 is_deleted 布尔字段是软删除最直观的做法，但直接裸用会导致所有业务查询都得手动写 WHERE is_deleted = false。漏写一次，逻辑就出错；新同学接手容易忽略；ORM 层可能绕过这个约束。更麻烦的是，硬编码过滤条件会污染业务 SQL，让可维护性直线下降。
PostgreSQL / MySQL 8.0+ 推荐用视图封装基础表
把原始表（比如 users）设为私有，只对外暴露一个视图 v_users，视图定义里固定加上软删除过滤：
CREATE VIEW v_users AS SELECT * FROM users WHERE is_deleted = false;
后续所有业务查询都查 v_users，不用再操心过滤。注意两点：
-
is_deleted字段类型建议用BOOLEAN（PG）或TINYINT(1)（MySQL），避免用字符串导致索引失效 - 视图不支持直接 INSERT/UPDATE，写操作仍需走原表，所以得配套封装存储过程或应用层校验
- 如果要查“含已删除数据”的管理后台，单独建
v_users_all视图，避免混用
ORM 层（如 Django、Laravel、MyBatis）必须统一拦截查询
数据库层无法强制所有客户端走视图，尤其当多个服务共用同一库时。这时 ORM 是最后一道防线：
- Django：重写
QuerySet的get_queryset()，在Manager中默认加filter(is_deleted=False) - Laravel：在模型中定义
boot()方法，用static::addGlobalScope()注入全局作用域 - MyBatis：用
Interceptor拦截StatementHandler，对未显式包含is_deleted的 SELECT 语句自动追加条件 - 关键点：全局作用域/拦截器必须可关闭（比如加参数
withTrashed()），否则连回收站功能都做不了
DELETE 和 RESTORE 操作必须原子且带审计
软删除不是 UPDATE 一行那么简单。真实场景需要：
- UPDATE 同时更新
is_deleted、deleted_at、deleted_by字段，三者缺一不可 - 恢复操作（restore）不能只改
is_deleted，还要清空deleted_at和deleted_by，否则时间戳和操作人信息会残留 - 所有软删/恢复操作建议走存储过程或事务函数，防止应用层部分更新失败导致状态不一致
- 千万别用
TRIGGER自动填充deleted_at——MySQL 的 BEFORE UPDATE 触发器无法可靠捕获当前时间，PG 虽支持但增加调试复杂度
最易被忽略的其实是「跨库关联」：当 orders 表软删除了，但 order_items 表没同步处理，JOIN 查询就会漏数据。这类场景必须靠外键约束 + 应用层级联逻辑兜底，没有银弹。
