软删除把记录标记为不可用，便于在规定期限内恢复误删；它不等于实际清除数据，也不能成为心理健康信息永久留存的理由。回收站、依法保留、最终清理和备份到期，需要分别设计。
软删除解决的是误操作恢复
业务表可增加is_deleted或deleted_at，常规界面删除时更新标记，普通查询排除相应记录。下面的SQL只说明这种机制，不包含完整鉴权、事务或审计处理。
-- 说明性示例：软删除仍保留数据，须配合权限与到期清理
UPDATE psychological_records
SET is_deleted = 1, update_time = NOW()
WHERE id = 1024 AND is_deleted = 0;SQL的DELETE也不等于即时擦除所有磁盘副本，事务日志、备份等可能仍有记录。误删能否恢复取决于备份和恢复方案，不能断言任何物理删除都无法挽回。
回收站也有保存期限
《个人信息保护法》第十九条、第四十七条要求最短必要保存，并规定主动删除和请求删除的情形。依法需要保存或技术上难以删除时，适用的限制处理要求也需落实，不能只把界面隐藏就称为完成删除。
设计时明确可恢复期限、谁能查看回收站、谁能恢复、到期如何清理，以及与关联记录、搜索索引、缓存、文件和备份的关系。备份恢复后，应重新执行应删除记录的处理，避免已删除资料再次进入正常使用。
全局过滤要验覆盖范围
MyBatis-Plus逻辑删除说明介绍自动过滤等支持，但具体效果依赖框架与使用方式。自定义SQL、外部报表或直接数据库访问不能只靠一条统一配置假定安全。
对于这类心理软件项目，橙星云团队可以把逻辑删除过滤与回收站恢复作为数据管理方案一并设计：在适用的ORM查询路径统一加入有效记录条件，例如is_deleted = 0，减少业务代码重复判断；关联报表、自定义SQL和绕过ORM的路径则分别补上规则与测试。交付目标是让普通业务入口不再展示被标记删除的记录，同时让获授权的恢复流程可控，而不是凭一项配置保证全部SQL、所有JOIN永远无遗漏。
验收应覆盖按ID读取、列表、统计、JOIN、导出、缓存和恢复接口；关联表的删除状态也要按业务语义处理，避免把过滤条件放错位置改变查询结果。回收站访问与普通访问应分别授权并留必要记录。
唯一键和恢复冲突需要明确规则
软删除记录仍占用普通唯一索引。若业务允许删除后重用学号，可考虑只对有效记录设置唯一约束，例如PostgreSQL的部分唯一索引。多租户系统还需把租户范围纳入设计。
另一种方案是联合student_no与delete_token：有效记录使用固定值，删除时使用保证唯一的标记。时间戳未必足够精确，且重复删除、重新恢复和并发操作都需测试，不能声称必然避开所有冲突。
如果新记录已经使用原学号，恢复旧记录时应按明确规则处理冲突，不能悄悄覆盖。软删除、备份恢复与最终清除各有用途，实施前要把保留期限、访问权限和责任写清。