版本保留策略需明示
别名: 历史保留期限 · 版本过期 · snapshot retention
概念解释
历史不是无限的。产品会按时间、条数或套餐丢掉旧快照。保留策略需明示指：人在依赖历史之前就知道「多久以内的还能打开」，以及哪些操作会提前删掉快照（清空历史、降级套餐、文件移出团队）。它管的是过去能被指望到什么时候。列表怎么比较、恢复能不能反悔，都假定快照还在；策略不说清，这两件事会在某一天无声失效。把过长的列表归并成可读的摘要，是另一层机制，不是「会不会删」。
机制
人把历史当成保险。保险未写免责条款时，行为按「永远能拿回来」来计划：大胆改、晚几天再核对、用恢复代替自己备份。策略一旦在后台按 30 天或 100 条裁剪，保险在人不知道的时候到期。发现点通常很晚——出了事才打开历史，列表在某个日期断开。明示把「可恢复窗口」变成和软删除保留期同类的预期：人会在窗口内完成核对，或主动导出。套餐差异若只写在价目页，编辑文档的人看不到，等于没明示。自动清理若发生在人出差期间，回来第一件事不该是发现上周的稿已经不在。
怎么研究
先让人使用带历史的文档并依赖一次恢复，再在不预告的情况下按策略删掉更早的快照，看他们何时、如何发现，以及是否改变后续的保存习惯。比较：策略写在历史面板顶上、只写在帮助中心、完全不写。
自变量：保留天数或条数是否在历史入口可见、清理前是否通知、套餐变化是否重申新窗口。 因变量：误以为仍能恢复的次数、发现缺失的延迟、事后导出或改用外部备份的比例。
实验室很难真的等 30 天，可用压缩时钟（告知「系统将清理 7 天前的版本」并立即执行）来测预期，但要标明这与真实日历不等价。不要把「列表太长不好读」算进保留策略——那是归并，对象还在。
边界
受监管的行业可能被要求留存更久，产品策略不能短于法定期；此时明示的是法定期而不是产品想省的存储。本地文件没有云端历史，策略是「本机这份就是全部」，需要在无历史时说清，而不是假装有云端保险。用户主动删除某个版本与系统到期清理要分开写，避免人以为自己删不掉。加密空间里服务端看不见内容，仍可以按时间删包装后的快照，保留说明不能暗示客服能帮你找回明文。
怎么落地
- 在历史面板顶部写保留规则：「过去 30 天的版本可打开，更早的会删除」或「最近 100 个版本」。
- 清理前用一次不挡编辑的通知；套餐降级导致窗口缩短时，在生效前重复规则并提供导出。
- 被策略删掉的边界用列表的尽头表示（「更早的版本已按保留规则移除」），不要留下断号让人以为加载失败。
- 验证：问正在编辑的人「上周二那版现在还能打开吗」。答不出窗口，或打开历史才发现尽头未说明，策略就没有明示。再人为执行一次清理，看是否有人在无提示下找不到预期中的快照。