Java软删除实现与数据标记设计解析

Java中级项目软删除核心是用状态字段替代物理删除，通过标记（is_deleted）和筛选（统一过滤）实现数据可追溯与恢复；数据库加tinyint字段及索引，MyBatis-Plus用@TableLogic自动拦截，服务层提供软删/强制删双接口并统一处理关联查询。

Java中级项目中实现软删除，核心是用状态字段替代物理删除，既保留数据完整性，又满足业务可追溯、可恢复的需求。关键不在“删”，而在“标”和“筛”——标记删除状态，并在所有数据访问层统一过滤。

数据库层面：添加逻辑删除字段

在对应表中增加一个非空的整型或布尔字段（推荐使用tinyint(1)或smallint），如`is_deleted`或`status`。不建议用boolean类型（MySQL中实际存为TINYINT），避免ORM映射歧义。

• `is_deleted TINYINT(1) DEFAULT 0 COMMENT '0-未删除，1-已删除'`
• 配合添加普通索引：`INDEX idx_is_deleted (is_deleted)`，提升查询性能
• 已有表迁移时，执行`ALTER TABLE xxx ADD COLUMN is_deleted TINYINT(1) DEFAULT 0`，并补全历史数据默认值

实体类与ORM映射：声明逻辑删除标识

以MyBatis-Plus为例，直接在实体字段上加@TableLogic注解，框架会自动识别并拦截CRUD行为：

private Long id;
private String name;
@TableLogic
private Integer isDeleted; // 值为0/1，MP默认0=未删，1=已删

若用原生MyBatis，需手动在每个<select>语句末尾追加AND is_deleted = 0；更新时用UPDATE ... SET is_deleted = 1 WHERE id = ? AND is_deleted = 0确保幂等性。

服务层与接口设计：统一拦截与显式控制

软删除不是“藏起来”，而是有意识地暴露操作意图：

• 提供两个独立接口：deleteById(Long id)（执行软删除）和forceDeleteById(Long id)（仅限管理员，走物理删除）
• 列表查询默认只查is_deleted = 0的数据；如需查含已删数据（如回收站），显式传参includeDeleted = true，并在Service中分支处理
• 关联查询（如订单+订单项）时，主表和从表都需加软删除条件，避免“半删”数据污染结果

全局过滤与扩展考虑

为降低遗漏风险，可借助MyBatis-Plus的MetaObjectHandler自动填充创建/更新时间及删除状态；对复杂场景（如多状态生命周期），可用status字段替代is_deleted，定义枚举：NORMAL(0), DELETED(1), DISABLED(2)，再配合@TableField(fill = FieldFill.INSERT)和逻辑删除插件协同工作。