文档保留规则、归档策略与删除策略共同构成知识文档生命周期管理的规则体系。保留规则回答“要不要留、留多久、谁来决定”，属于约束层；归档策略和删除策略回答“到期之后怎么处置”，属于执行层。归档是“继续保存但退出日常使用”的出口，删除是“无继续保存义务后清除”的出口。理解三者的层级与衔接，能避免把归档当删除、把删除当归档，也能防止在保留期内误清文档。
要点总览（TL;DR）
- 文档保留规则是约束层，回答“要不要留、留多久、谁来决定”；归档策略与删除策略是执行层，回答“到期之后怎么处置”。
- 归档是“继续保存但退出日常使用”的出口，删除是“无继续保存义务后清除”的出口，两者不能互相替代。
- 保留期限未到之前，归档和删除都不应触发；到期评估后，才在继续保存、归档、删除之间做选择。
- 归档后的文档仍受保留规则约束，需要定期复核；删除前要再次核对保留义务，防止误删仍在保留期内的文档。
- 判断顺序可归纳为：先查保留规则，再看期限是否已到，到期后评估去向，归档后继续复核，删除前再次核对。
保留规则、归档策略、删除策略分别指什么
三个概念经常被并列提起，但它们处在不同层面。先把定义说清楚，后面的边界和流程才有共同语言。
文档保留规则
文档保留规则是对文档留存行为的约束性规定，通常包含四项内容：留存条件（哪些文档必须留、依据什么分类）、留存期限（保存多久，从什么时间点起算）、责任人（谁有权决定去留、谁负责复核）、处置依据（到期后依据什么判断继续保存还是清除）。保留规则本身不执行具体动作，它给出判断标准，让后续的归档或删除有据可依。在知识文档管理中，保留规则往往按文档类别设定，例如制度文件、合同附件、项目结项材料各自适用不同的留存要求。
归档策略
归档策略规定文档在什么条件下退出日常使用、转入长期保存状态。归档后的文档通常不再出现在日常协作的主视图里，但仍被完整保存，可以按权限检索和调阅。归档解决的是“文档还有保存价值，但已经不需要频繁使用”这一情形，它改变的是文档的使用状态，不改变文档的留存义务。
删除策略
删除策略规定文档在什么条件下被清除，以及由谁执行、经过什么确认。删除是生命周期中不可逆性最强的动作，因此删除策略通常包含判定条件（保留期已满且无继续保存义务）、执行权限（谁可以发起、谁需要确认）和补救安排（是否进入回收站、保留多久）。删除策略处理的是“保存义务已经结束”的文档。
三者共同服务于知识文档生命周期管理：保留规则划定约束，归档策略和删除策略分别处理约束到期后的两种去向。
三者的边界：保留规则管约束，归档与删除管处置
把三者放在同一张图上看，层级关系很清楚：保留规则是约束层，归档策略与删除策略是执行层。约束层回答“要不要留、留多久、谁决定”，执行层回答“到期后怎么处置”。
归档与删除是保留规则的两个不同出口，彼此不能替代。归档不等于删除：归档的文档仍然存在、仍可检索，只是退出了日常协作视野；删除也不等于归档：删除意味着文档被清除，不再作为可调阅的内容存在。把两者混用，常见后果是该留的被清掉，或者该清的长期占用检索结果和管理注意力。
一个关键前提是时间顺序：保留期限未到之前，归档和删除都不应被触发。归档虽然保留文档，但它改变使用状态，属于到期评估之后的处置动作；删除更是只能在保留义务结束后执行。换句话说，保留规则先于处置动作生效，处置动作只能在保留规则允许的范围内发生。
边界清晰之后，执行中的争议会少很多。当有人问“这份文档能不能删”，正确的问题顺序是先查保留规则：它属于哪一类、保留期到没到、有没有合规义务要求继续保存；只有这些都有明确答案，才轮到选择归档还是删除。
三者如何衔接：一条文档从创建到处置的机制
把三个概念放进一条时间线，可以看到保留规则如何驱动归档与删除动作。下面按文档生命周期的顺序展开。
创建时确定保留属性
文档创建或入库时，就应确定它的保留属性：属于哪个类别、适用多长的保留期限、责任人是谁。这一步是后续所有判断的基础。属性缺失的文档，到期时无法评估，往往被迫长期滞留，既占资源也增加管理成本。
保留期内维持活跃或只读状态
保留期内，文档处于活跃使用或只读引用状态。此时归档与删除都不触发。文档可以正常编辑、评审、被引用，版本变化也在这个阶段发生。保留期内的核心管理动作是维护内容准确性和访问权限，而不是处置。
到期评估
保留期限到达时，依据保留规则做一次评估，判断三种可能：仍需继续保存（延长保留期）、退出日常使用但继续保存（归档）、无继续保存义务（进入删除流程）。评估应由保留规则指定的责任人执行或复核，评估结论要留痕，便于日后追溯。
归档后的持续约束
文档进入归档状态后，仍受保留规则约束。它可以被检索、被有权限的人调阅，但不再参与日常协作和编辑流程。归档不是终点，而是保存义务在新状态下的延续；归档文档同样需要到期复核。
删除前的核对
删除执行前，需要再次核对保留规则与合规义务，确认文档确实已过保留期、没有未结的调阅需求或外部要求。核对通过后按删除策略执行，并视需要保留操作记录。这一步是防止误删仍在保留期内文档的最后关口。
在工具层面承载这套机制时，文档状态、版本记录和权限控制需要配合。以 ONES Wiki 为例，文档实时同步并记录所有页面版本，支持随时查看与回滚（F1）；支持为多种角色配置不同的读写权限（F3）；误删除的页面可从回收站恢复（F2）；页面树与搜索功能帮助团队在归档后仍能定位内容（F4）。这些能力对应的是生命周期中的状态维护、权限约束和误操作补救，保留期限的具体配置方式则需在选型时向厂商确认。
容易混淆的相邻概念：归档、备份、冻结、删除
执行保留规则时，几个相邻概念常被混用，导致处置动作走偏。下表按同一口径对照它们的区别。
| 概念 | 解决的问题 | 与保留规则的关系 | 常见误用 |
|---|---|---|---|
| 归档 | 文档退出日常使用但继续保存 | 保留规则到期评估后的一种处置出口 | 把归档当成删除，或归档后不再复核 |
| 备份 | 系统故障或数据损坏后的恢复 | 容灾手段，不改变文档的留存义务 | 用备份代替归档，认为有备份就不必保留原件 |
| 冻结 | 临时限制文档修改 | 使用状态限制，与留存期限无关 | 把冻结当成归档，冻结解除后文档仍在日常视图中 |
| 删除 | 清除文档 | 保留规则确认无保存义务后的处置出口 | 在保留期内直接删除 |
| 逻辑删除/回收站 | 删除后的短期可恢复状态 | 删除策略的补救环节，不等于最终清除 | 把进入回收站当作已完成删除，忽略后续清理 |
还有一组容易混淆的是保留规则与内容审核、发布状态的区别。内容审核和发布状态管的是“内容能不能发布、以什么状态对外呈现”，属于内容质量与可见性控制；保留规则管的是“文档留存多久、到期怎么处置”，属于生命周期的时间维度。一份已发布文档同样受保留规则约束，发布状态不能替代保留期限的判断。
一个具体例子：制度文档的保留、归档与删除
以下为演示情景，用于说明判断顺序，不代表任何产品的默认配置。
某团队的一份管理制度文档设定保留5年，期间不得删除。第3年，新版制度发布，旧版被替代，文档进入归档状态：它退出日常协作视图，但仍可被检索和调阅，供追溯历史条款使用。第5年到期评估时，若确认没有合规义务或未结调阅需求，则按删除策略清除；若存在外部要求继续保存，则延长保留期，文档继续以归档状态存在。
如果这份文档在保留期内被误删，后果是历史条款失去可查依据，可能影响审计或争议处理。纠正方式取决于删除策略的补救安排：若删除进入回收站且尚在可恢复范围内，可由有权限的人员恢复；若已超出补救范围，则需要从备份或其他留存副本中找回，并复盘删除权限与流程。这也说明删除前的核对环节不能省略。
从这个例子可以归纳出可迁移的判断顺序：先看保留规则，确认文档类别、保留期限和责任人；再看期限是否已到；到期后评估继续保存、归档还是删除；归档后继续受保留规则约束并定期复核；删除前再次核对保留义务。按这个顺序处理，归档与删除各归其位，保留规则始终是判断的起点。
常见问题
保留期限还没到，但文档已经没人用了，可以先归档吗？
归档属于到期评估之后的处置动作，它改变文档的使用状态。在保留期限未到时提前归档，会让文档过早退出日常协作视野，也可能影响仍在引用它的流程。更稳妥的做法是保留文档的活跃或只读状态，同时记录使用频率下降的情况，等到期评估时再决定是否归档。如果确实需要减少日常干扰，可以考虑用权限或视图控制可见范围，而不改变文档的留存状态。
归档和备份都保留了文档，为什么不能互相替代？
两者解决的问题不同。归档是生命周期处置，处理的是“文档还有保存价值但不再频繁使用”，归档后的文档仍可被检索和调阅，仍受保留规则约束。备份是容灾手段，处理的是系统故障或数据损坏后的恢复，它不改变文档的留存义务，也不提供日常调阅入口。用备份代替归档，会导致文档在日常视图中消失却缺少可检索的归档入口；用归档代替备份，则无法应对数据损坏场景。
删除策略里的“回收站”算不算已经完成删除？
不算。逻辑删除或进入回收站是删除策略的补救环节，文档仍可恢复，不等于最终清除。完整的删除策略需要说明回收站的保留时长和后续清理规则，否则会出现“以为删了、实际还占着”的情况。执行删除时应区分两个节点：发起删除（进入可恢复状态）和最终清除（不可恢复），并在流程中明确各自的责任人。
内容审核通过、已经发布的文档，还需要受保留规则约束吗？
需要。内容审核和发布状态管的是“内容能不能发布、以什么状态对外呈现”，属于内容质量与可见性控制；保留规则管的是“文档留存多久、到期怎么处置”，属于生命周期的时间维度。一份已发布文档同样有留存期限和处置要求，发布状态不能替代保留期限的判断。两者是并行的两套控制，执行时不要用其中一个替代另一个。
在工具里落地这套规则时，需要重点确认哪些能力？
可以从三个动作去核对：文档状态能否区分活跃、归档等不同阶段；版本记录是否完整、能否回滚；误删除后是否有恢复机制。以 ONES Wiki 为例，文档实时同步并记录所有页面版本，支持随时查看与回滚（F1）；支持为多种角色配置不同的读写权限（F3）；误删除的页面可从回收站恢复（F2）；页面树与搜索功能帮助团队在归档后仍能定位内容（F4）。保留期限的具体配置方式、回收站保留时长等细节，建议在选型时向厂商确认。
