H8.11.4version history compaction设计研究
版本数量过多时需要归并策略，避免历史列表失去可读性
别名: 版本折叠 · 历史归并 · snapshot compaction
概念解释
自动保存会把一天写成上百条。列表若逐条平铺，人扫不到里程碑，历史等于不可用。归并是按时间桶或「无实质改动」把多条收成一组可展开的摘要，让首屏仍是可读的时间轴。对象往往还在，只是默认不占一行——这和到期删除不是一回事。保留策略说会不会删；归并说怎么读。主动保存的点应尽量不被折进自动桶里消失。
机制
可读性依赖列表长度与条目意义。条目意义来自「这一条和上一条差在哪」。相邻自动点常常只差几个字，独立成行没有新信息，却占用扫视。归并按小时或按「连续自动保存」成组，组上写时间范围和一句「约 n 次自动保存」，需要时再展开。若归并把主动保存也吞掉，人找不到立过的碑。若归并不可展开，等于把那些自动点从可打开变成不可达，防丢的价值没了。算法若按固定条数硬切（只留 50 条），会在忙碌的一天丢掉下午，这是删除冒充归并。组的边界还要可理解：不要把两天的稿折进同一组。
怎么研究
生成含大量自动点和少数主动点的历史，请人「找到今早你保存的」和「打开崩溃前最后一次自动」。比较平铺、按小时折叠且可展开、硬截断只留最近 N 条。
自变量：折叠规则、主动点是否保持独立行、折叠组能否展开到每一条。 因变量：找到主动点的时间、误以为中间的自动点已删除、展开后能否打开具体一条。
实验室列表若只有十几条，归并无必要。要把自动点做到必须滚动。不要把「保留 30 天」的删除当成折叠失败。
边界
本来就稀疏的手动检查点列表不需要归并。法规要求每条改动平铺可审时，折叠只能是视图，导出和审计接口仍要平铺。归并算法销毁底层快照以省存储，那就变成保留策略，必须按删除来明示，不能只在 UI 上折叠。跨时区的「按天」分组要以文档时区或作者时区写明，避免边界上的点跑错组。
怎么落地
- 默认按时间桶折叠连续自动保存；主动保存、发布、命名版本保持独立行。
- 每一组可展开到具体快照，展开后仍能比较和恢复。
- 不要用「只保留最近 50 条」冒充折叠；若必须删，走保留策略的明示删除。
- 验证：在上百条自动点里找出两次主动保存，应无需遍历每一行。展开一个小时桶，应能打开其中一条自动快照。问人被折叠的点还在不在，答案应是在，而不是「被删了」。