为什么档案同事会坚持「GIF 与 WebM 都要留」而不是只留更小的 WebM？
GIF 仍是许多设计工具与 IM 的「像素真源」：调色板、透明索引与循环点定义都写在 GIF 语义里；WebM 则是面向播放器的现代视频封装。用户常搜「gif webm 归档」「品牌 动效 dam」「vp8 vp9 长期 可读」「动图 母版 双轨」「对象存储 生命周期」——怕的是「十年后没人知道当年怎么导出」。只留 WebM 可能在色彩迁移或解码器迭代时丢细节；只留 GIF 又可能在带宽与前端嵌入场景吃亏。双轨应互链哈希、操作者与工具版本，并在 sidecar 写循环点与安全区说明。另：合规检索常要证明「对外投放与内部母线一致」，缺一代源会让审计卡壳。对象存储若开启版本控制，同名 WebM 反复覆盖会产生删除标记与清单膨胀，应在对象键里带日期或语义版本号，避免「永远叫 final.webm」导致灾难恢复时捞错代际。灾难恢复演练除了随机抽文件播放，还应抽元数据导出核对工具版本、操作者与色彩意图字段是否完整，以免演练报告写通过但审计字段仍缺。Ai2Done 归档变体建议「先冻结源 GIF 命名—再生成 WebM—最后登记保留期限与解冻审批人」。
归档变体：GIF 与 WebM 双轨入库流程
- 冻结当期 GIF 源文件与调色板说明，选择「长期归档版」；在工具里选偏兼容的 VP8 或保守 VP9 档位，避免激进实验参数写进母线。
- 导出 WebM 后计算 GIF 与 WebM 双哈希，写入 DAM 元数据与工单；若对象存储有生命周期，标注「禁止自动删除 GIF 源直至品牌书面批准」。
- 每年做一次可读性抽检：随机抽五条在最新版 Chrome 与档案专用离线机解码；发现问题再触发迁移项目而不是临时手改。
GIF 转 WebM（归档）问答
若未来全站前端只嵌入 WebM，我是否可以在三年后直接删除 GIF 源以节省一半存储而不更新保留策略文件？
高风险：应先跑法务与品牌联合评估，启用版本化迁移日志；删源前要有书面批准与替代可复现链路，否则争议时无法解释像素差异。
当 VP9 母线与 VP8 兼容副本在同一桶里并存时，是否必须在文件名与对象键里显式写 codec 代际与日期以免 CDN 缓存键与用户下载混淆？
是：文件名与对象键都应含编码族与日期；缓存分层、签名 URL 与灰度发布策略也要区分代际，避免用户或下游自动化脚本命中错误版本还自以为校验通过。
外部审计要证明「当年实际外发物料与内部母线像素一致」，我只提供最终 WebM 的 SHA256 哈希是否通常就足够过关？
不足：应提供 GIF 源、WebM 派生、发布截图、审批邮件与操作日志互证；单一哈希无法说明是否事后替换过时间线或是否混用了另一场 Campaign 的导出参数。
迁移到冷归档层后单次解冻带宽与费用太高，我是否可以用低帧抽帧预览 WebM 完全代替全量解冻抽检并仍声称治理合规？
可做统计抽样加低帧预览，但抽样比例、随机种子与豁免条件要写进治理文档并经数据治理委员会签字；遇到高价值 Campaign 仍应安排预算做全量解冻核验。
外包设计师用未知版本工具导出的 Campaign GIF，我是否应暂时禁止入库直到对方补齐工具名、版本号与色彩工作空间声明这类参数记录？
应先补录工具、版本、色域与循环点说明再入库；否则未来迁移只能猜参数，审计与品牌复盘都不接受「不知道当时怎么来的」这种口头解释。