题干与适用场景
一个制品仓库用哈希摘要作为对象地址。请解释内容寻址的优点与边界，并说明如何从旧哈希迁移到新哈希而不破坏客户端、缓存和签名。
OCI 内容描述符把摘要作为内容标识，并建议消费不可信来源前重新计算摘要；Git 的哈希迁移文档展示了逐仓库过渡的思路。面试重点是区分完整性、身份、可用性和迁移兼容性，不能把“摘要相同”说成绝对安全证明。
面试官考察点
面试官会看你是否理解哈希作为地址、去重键和校验值的不同职责，能否说明碰撞、二次原像、预映像和算法降级的边界，并设计别名、索引、缓存、签名、垃圾回收和回滚。还要判断何时需要签名或可信来源，而不是只依赖摘要。
回答前需要澄清的问题
- 对象是容器层、构建产物、备份还是任意用户文件？
- 摘要是否直接出现在 API、URL、数据库、日志、签名和客户脚本中？
- 当前算法、编码、规范化规则、对象大小和碰撞处理是什么？
- 客户端能否理解算法前缀，是否存在离线、旧版本或第三方镜像？
- 迁移目标是增加算法、替换默认算法，还是消除已不推荐算法？
- 旧摘要需要验证多久，如何保留审计、签名和可追溯性？
30 秒回答框架
“内容寻址把规范化后的字节摘要作为稳定 ID，便于去重、缓存和完整性校验，但它不证明来源、权限或可用性。我会先把算法和编码写进摘要格式，保留旧摘要到新摘要的索引和可读别名，再让新客户端优先使用新算法，旧客户端继续读取旧地址。迁移期间双写或按需计算新摘要，签名同时覆盖算法、摘要和上下文；所有消费方重新验证大小与摘要。用命中率、重算成本、客户端错误、签名验证和回滚演练作为退出门槛。”
分步骤深入解答
第一步：定义稳定的内容字节
先明确摘要输入是原始字节还是规范化表示。压缩层、换行、JSON 字段顺序或元数据改变都会产生不同摘要；如果业务需要语义相同但字节不同的对象，另设语义版本，不要偷偷规范化导致签名和审计失真。
第二步：区分摘要、标签和签名
摘要回答“拿到的字节是否与标识匹配”，标签回答“用户想引用哪个版本”，签名回答“谁在什么上下文批准了它”。标签可能移动，摘要通常不可变；签名应覆盖算法、摘要、媒体类型、用途和时间，不能只签一个可变标签。
第三步：说明安全边界
碰撞风险、二次原像风险和预映像风险不同；算法强度也会随时间变化。摘要验证不能替代认证、授权、恶意内容扫描或可用性保证。来自不可信源的内容应先检查大小和格式，再计算摘要，避免在巨大或恶意输入上做昂贵处理。
第四步：设计双算法对象模型
让摘要包含算法前缀和编码，内部索引支持一个对象对应多个摘要。保留主对象 ID、旧摘要、新摘要、大小、媒体类型和生成时间；API 能力声明决定默认返回哪种摘要，但客户端不能把未知算法静默当成旧算法。
第五步：规划迁移路径
先让读取端理解新格式，再让写入端产生新摘要；旧摘要可通过索引查找同一对象。对热对象预先重算，对冷对象按读取懒加载，记录失败和队列。新客户端优先新摘要，旧客户端通过别名或内容协商继续工作，不能在同一地址返回不同字节。
第六步：处理缓存、签名与供应链
缓存键、CDN、镜像清单、SBOM、签名和审计事件都要能携带算法前缀。签名验证必须检查摘要、算法、上下文和证书信任；迁移期间可以保留双签名，但要明确哪一套是发布门槛。镜像拉取先核对摘要再解压或执行。
第七步：控制垃圾回收与回滚
只有旧、新摘要和所有别名都没有引用时才能回收对象。迁移索引、重算队列和签名状态要可恢复；若新算法实现出现错误，暂停新写入并回到旧默认，但保留已生成的新摘要和映射。回滚不能删除仍需验证的历史签名。
第八步：用指标证明迁移完成
监控双摘要覆盖率、读取命中率、重算吞吐、大小不匹配、未知算法错误、签名失败、缓存命中和回滚次数。按客户端版本和对象类型分层，设置停止线。旧摘要流量低于阈值且审计、签名和第三方验证完成后，才停止新写入旧算法。
设计取舍与边界
一个对象多个摘要
多摘要提高迁移兼容性，却增加索引、签名和缓存复杂度。把摘要作为可枚举属性而不是互相覆盖，明确哪个是默认显示、哪个用于验证。
预计算与按需计算
预计算降低首次读取延迟，但消耗大量 CPU 和存储带宽；按需计算节省冷数据成本，却可能造成尾延迟。按热度、大小和客户端期限分层，并允许暂停队列。
摘要验证与来源认证
摘要可验证字节未被改变，不能证明发布者身份。供应链需要签名、透明日志或可信分发；权限系统仍决定谁能读取、推送或删除对象。
失败演练与演进计划
客户端拒绝带算法前缀的摘要
提供版本化 API、别名和兼容字段，记录拒绝率。不能把新摘要截断成旧格式，也不能让客户端猜测算法。
重算后对象字节发生变化
冻结输入版本，比较大小、媒体类型和校验值，定位压缩或规范化差异。新摘要必须指向确定字节；若语义相同但字节不同，建立新对象版本。
新摘要签名验证失败
检查签名上下文、证书链、算法策略和时钟，再按版本回退读取。保留旧签名验证能力，禁止为恢复发布而跳过签名检查。
常见误区与追问
误区一：把摘要当成访问控制
追问：知道摘要的人能否读取对象？候选人应区分不可猜测、鉴权、授权和加密。
误区二：把标签当成不可变 ID
追问：标签移动或回滚时缓存和签名怎么办？应使用摘要锁定内容，签名覆盖上下文。
误区三：迁移只改数据库字段
追问：API、镜像清单、CDN、客户端、签名、日志和垃圾回收如何同步？
误区四：只测摘要计算速度
追问：如何验证大小不匹配、未知算法、尾延迟、签名失败和第三方兼容？
延伸追问与参考答案
为什么 OCI 还记录对象大小？
大小可在哈希前拒绝明显异常输入，也帮助客户端预估下载和资源消耗。它不是完整性证明，仍需对最终字节重新计算摘要。
迁移期间能否让一个 URL 同时代表两个摘要？
同一 URL 必须稳定返回同一字节和语义。可以让一个逻辑别名解析到不可变摘要，或在 API 中返回多个明确的摘要字段，但不能按客户端随机返回不同内容。
什么时候可以停止旧算法？
新客户端覆盖、双摘要映射、签名验证、缓存、第三方拉取和审计指标都达标，且旧摘要流量低于退出阈值后，先停止产生旧摘要，再经过验证窗口撤销旧写入。历史读取和签名验证按保留期限继续支持。