MyBatisPlus逻辑删除配置？用于标记无效的语音生成任务
在构建AI语音合成系统时，我们常常会面临一个看似简单却影响深远的问题：当用户提交的语音生成任务因参数错误、资源超限或主动取消而失败时，该如何处理这条“无效”记录？
直接从数据库中物理删除，操作干净利落。但一旦这么做，后续若要排查“为什么这个请求没出声？”、“是不是模型出了问题？”这类问题时，就会发现——关键上下文已经丢失。没有输入文本、没有配置参数、甚至连谁发起的都不知道。这种“黑盒式”的失败，对系统的可维护性和可观测性是巨大打击。
这正是软删除机制的价值所在。
以 IndexTTS2 这样的语音合成平台为例，每个语音生成任务都包含原始文本、声线选择、语速调节等重要信息。即使任务最终未能成功执行，这些数据依然具有极高的分析价值。与其一删了之，不如将其“标记为无效”，既不影响正常业务流程展示，又能保留现场供后续追溯。这就是逻辑删除的核心思想。
MyBatisPlus 作为当前 Java 生态中最主流的持久层增强框架之一，原生支持逻辑删除功能，并通过插件化设计实现了高度自动化。开发者无需在每个查询中手动添加AND deleted = 0条件，也不必反复编写更新状态的 Service 层判断。只需一次配置，即可让整个数据访问层自动遵循软删除规则。
来看一个典型的场景：用户通过 WebUI 提交了一条语音生成请求，后端服务创建一条tts_task记录并进入处理队列。如果任务中途失败或被取消，调用方只需像往常一样执行：
taskMapper.deleteById(taskId);你可能以为这会触发一条DELETE FROM tts_task WHERE id = ?的 SQL，但实际上，在 MyBatisPlus 的拦截机制下，它会被自动重写为：
UPDATE tts_task SET deleted = 1 WHERE id = ? AND deleted = 0;更神奇的是，此后所有普通的查询操作，例如：
taskMapper.selectList(null);都会被自动附加WHERE deleted = 0条件，确保返回结果中永远不会出现已被“删除”的任务。这一切都在幕后完成，业务代码完全无感。
其背后的关键在于LogicDeleteInterceptor拦截器。它是 MyBatisPlus 插件体系的一部分，基于 MyBatis 的 Executor 拦截机制，在 SQL 构造阶段动态注入逻辑删除条件。无论是selectById、selectList，还是复杂的QueryWrapper查询，只要未显式指定deleted字段条件，框架就会自动补全默认过滤规则。
而这一切的前提，是在实体类中标注@TableLogic注解：
@Data @TableName("tts_task") public class TTSTask { private Long id; private String textContent; private String voiceType; private Integer status; @TableLogic private Integer deleted; // 0:未删除, 1:已删除 }这个注解告诉 MyBatisPlus：“请将此字段视为逻辑删除标志”。配合全局配置，还能自定义值映射关系，比如使用'Y'/'N'或-1/1等非标准数值：
@Bean public ConfigurationCustomizer configurationCustomizer() { return configuration -> { configuration.setLogicNotDeletedValue(0); configuration.setLogicDeletedValue(1); }; }这种灵活性使得该方案能轻松适配各种已有数据库设计规范。
再深入一点，你会发现这套机制不仅提升了开发效率，更重要的是改变了我们对待数据的态度——从“用完即弃”转向“谨慎留存”。
试想这样一个情况：某天突然收到反馈，“最近三天有几位用户的语音生成总是失败”。如果没有逻辑删除，你只能依赖日志系统去拼凑线索；而有了软删除，你可以直接查询数据库中所有deleted = 1且create_time在过去72小时内的任务，快速统计失败模式、高频关键词、共用声线类型……甚至可以训练一个简单的分类模型来预测潜在失败任务。
当然，任何机制都有边界。逻辑删除并不意味着“永不清理”。随着系统运行时间增长，大量已标记删除的任务仍会占用存储空间并影响查询性能，尤其是当表中缺乏有效索引时。
因此合理的工程实践应包括：
- 为
deleted字段建立索引：特别是当表数据量超过十万级时，单靠主键无法高效过滤活跃数据。
sql ALTER TABLE tts_task ADD INDEX idx_deleted (deleted);
制定定期归档策略：例如通过定时任务将超过30天的
deleted=1记录迁移到历史表或冷存储中，保持主表轻量化。权限隔离控制：普通用户接口默认只返回有效任务；管理员后台则可通过特殊参数查看全部状态，避免敏感信息泄露。
与业务状态字段协同管理：不要把
deleted当作万能状态位。建议保留独立的status字段表示任务生命周期（如“排队中”、“生成中”、“已完成”、“已取消”），而deleted仅用于标识是否对外可见。两者结合，才能实现清晰的多维状态机。
还有一个容易被忽视的设计细节：字段命名一致性。虽然你可以命名为is_deleted、del_flag或status_code，但统一采用deleted并配合团队规范，能极大降低新成员的理解成本。毕竟，工具的威力不仅取决于功能强弱，更在于能否被稳定复用。
回到最初的问题：为什么要对无效语音生成任务做逻辑删除？
答案其实很朴素——因为每一次失败，都是改进的机会。那些被取消的任务里，可能藏着用户体验的痛点；那些参数异常的请求中，或许暴露了前端校验的漏洞；甚至某些重复提交的背后，暗示着接口重试机制的设计缺陷。
而 MyBatisPlus 的逻辑删除能力，就像给系统装上了一个“数据快照”功能。它不阻止你“删除”，只是让你删得更有分寸、更有依据。不是为了逃避问题，而是为了更好地解决问题。
在这个越来越强调可观测性与可追溯性的时代，真正的健壮系统，不是从不出错的系统，而是出错之后仍能说清楚“发生了什么”的系统。逻辑删除虽小，却是通往这一目标的重要一步。
未来，随着 AI 应用场景不断复杂化，任务类型的多样性也会增加——语音生成、视频合成、文本摘要……这些长周期异步任务尤其需要完善的生命周期管理。而基于 MyBatisPlus 的软删除方案，提供了一个低侵入、高可靠的基础支撑。它不需要改变现有编码习惯，却能在关键时刻为你留住最关键的那条记录。
有时候，一个好的设计，并不是让人惊叹“太巧妙了”，而是让人感觉“本来就应该这样”。
