工程上最危险的不是完全不可用，而是在理想环境里正常、进入真实网络和真实数据量后悄悄失去边界。 主表删除不等于数据消失：搜索索引、聚合表、对象存储、日志和备份都有自己的生命周期。保留矩阵应列出每个副本与最长清除时间。
风控既要限制滥用，也要限制自己收集的数据。优先使用短期、粗粒度、可解释信号，并为共享网络、弱网和辅助技术保留恢复与申诉路径。
工程边界与取舍
这项能力横跨客户端、网络与服务端，局部最优很容易制造全局故障。工程决策需要同时约束两端行为、持久化事实和运维预算。
- 数据带 expiresAt 和 policyVersion；在线清理可重入并发出删除事件，备份通过滚动过期而非就地修改，legal hold 显式阻止但需审计。
- 所有输入都设置大小、次数和时间预算，并在超限时返回可操作的稳定错误码。
- 兼容性通过显式能力协商决定，旧客户端得到可解释的降级路径，而不是进入半可用状态。
“数据保留不是一个 TTL：备份、派生表和日志都要能删”的交付标准是正常路径可用、异常路径收敛、资源有界，并且用户能理解系统为何采用当前状态。 这样得到的不是演示代码，而是能解释、能降级、能回滚的生产能力。
生产环境会怎样出错
不要把异常路径理解成弹一次提示。它还包括在途工作如何停、对端如何获知、残留数据如何处置，以及下一次操作是否会继承旧状态。
- 清理任务只按 createdAt 扫描会漏掉政策缩短后的旧数据；派生聚合若能反推出个体，也不能以“匿名统计”无限保留。
- 旧响应在新任务建立后迟到，如果没有版本隔离，会把健康状态覆盖成失败或再次启动已取消工作。
- 指标标签直接包含用户或任务标识，既制造高基数成本，也让诊断数据泄露不必要的身份信息。
把测试跑成闭环
验证需要先写预期状态轨迹，再执行故障注入。每个阶段同时核对用户可见结果、两端协议状态、持久记录和资源计数，才能证明闭环成立。
- 创建带唯一 canary 的完整数据链，执行用户删除与策略到期后逐层查询在线库、对象、索引、日志和可恢复备份窗口。
- 让刷新、取消、超时和远端完成在同一调度窗口发生，断言系统只产生一个终态和一次副作用。
- 用故障注入验证告警先于用户投诉触发，并确认值班人员能从有限证据定位到具体阶段。
当实现能够安全降级、重复执行不产生额外副作用、故障指标早于投诉出现时，这项能力才算具备长期维护价值。