本章说明根平台形成发布事实后，资源包、DID 文档、元数据、哈希、凭证和发布证明如何经由内容分发平台传播到获得授权的发现服务节点。章节重点区分发布任务、传播材料、同步游标、接收校验和本地索引等状态，说明批量传输、重试、部分失败、幂等和恢复如何保证传播过程可追踪，而不把内容可取得误认为资源已经被所有发现节点应用。

10.1 分发模型与内容类别

内容分发采用“发布事实先形成、传播材料后传输、发现节点再次验证”的模型。一个资源版本的传播集合通常包括资源包（ResourcePackage）、DID文档、资源元数据、哈希、注册凭证、根平台可信发布证明、生命周期状态、授权域和必要的摘要或索引提示。摘要可以优化同步效率，但不能替代完整资源包和证明的校验。

传播链路中有三类容易混淆的对象：根平台产生发布任务和发布游标，内容分发平台保存可取得的资源材料，发现服务节点将验证后的材料转换为本地索引。它们分别代表“根平台决定传播什么”“内容在哪里取得”和“哪个节点已经应用什么”，不能因为同一资源 DID贯穿三者，就把三种状态合并成一个全网状态。

10.2 内容分发服务职责

内容分发平台负责发布材料的托管、获取、批量传输、缓存和传输状态反馈。内容分发发布器可以从根平台取得发布任务，按发布游标组织资源包并写入内容分发平台，再把成功或失败结果回报根平台。该服务不产生资源控制权、节点授权或根平台可信发布证明，发现服务节点仍需以自身验证结果决定是否应用材料。

当前参考实现的批量发布响应包含已发布项目、失败项目和对应发布游标。发布器只有在响应可解析且项目数量与请求一致时，才确认这一批任务的处理结果；请求成功但响应缺少游标或项目状态不完整时，应按异常处理，不能直接确认整批发布完成。

10.3 分发清单与发布检查点

发布清单是发现服务节点确定同步范围和验证对象的入口，发布检查点则把传播状态拆分为已发送、已接收、已校验和已应用。清单中的资源 DID、包版本、包哈希和发布游标用于关联资源版本，通知批次中的目标节点和序列范围用于关联一次传播操作。发现服务节点只有完成校验并写入索引后，才可以报告该项目已应用。

10.4 资源包、元数据、证明与索引数据分发

10.4.1 资源包分发

资源包是面向发现服务节点的主要完整载荷，至少应通过资源 DID、资源包版本和包哈希与发布清单关联。内容分发平台可以提供完整包或按清单提供增量材料，但接收方必须在写入可信索引前重算哈希并验证根平台可信发布证明。

当前内容分发平台的单项发布入口为 POST /cdn/resources，批量发布入口为 POST /cdn/resources/batch。单项请求由 ResourceCdnPublishRequest 承载，包含 ResourcePackage 和 upstreamAuth；批量请求由 ResourceCdnBatchPublishRequest 承载，包含带 publicationCursor 的条目和公共上游认证。发布成功的单项响应包含 status: published、资源 DID、资源类型、包版本和 publicationCursor；批量响应还区分 acceptedCount、failedCount、成功项目和失败项目，不能用批次 HTTP 成功替代所有项目已应用。

发现服务节点可以通过 POST /cdn/resources/batch-get 按资源 DID 批量读取资源包，或通过资源索引接口按 afterCursor 增量读取。批量读取返回请求数量、命中数量和资源包项目；增量索引返回 items、count、afterCursor、nextCursor 和 hasMore。这些游标分别服务于批量读取、列表分页和传播同步，不能相互替代。

10.4.2 DID Document 与元数据分发

DID文档和资源元数据可以随资源包传输，也可以按资源 DID、版本和哈希单独取得。分开发送时，发现服务节点不得先应用其中一部分而丢失关联关系；DID文档、元数据和包外摘要不一致时，应拒绝组合并记录缺失或冲突字段。

10.4.3 VC 与根平台证明分发

注册凭证用于说明注册服务节点的登记事实，根平台可信发布证明用于说明根平台接受特定资源版本。两者应按资源 DID、版本和哈希关联传输，接收方应分别验证签发者、签名、覆盖范围和当前状态，不能因注册凭证存在就跳过根平台证明检查。

10.4.4 索引数据分发

索引数据是发现服务节点根据已发布材料形成的派生读模型，可以包含资源摘要、能力标签、端点引用、生命周期状态和新鲜度信息。索引数据不应被回传为新的根平台事实；发现服务节点必须能够说明索引记录对应的发布游标、校验时间和授权域。

10.5 分发边界完整性验证

发现服务节点接收材料后，应先校验通知目标、清单范围和载荷结构，再按资源 DID、资源类型、版本、三类哈希、根平台可信发布证明、生命周期和授权域完成验证。校验失败的对象不得写入可信发现索引；可以写入拒绝记录以支持诊断和重试。传输成功但内容损坏属于完整性失败，材料缺失属于可恢复的获取失败，治理状态已撤销属于阻止应用的状态失败。

接收方的负向验收可以分别只改变包内容、证明绑定的资源 DID或当前发现服务节点的授权域。三种情况下，前两者应分别在哈希或证明绑定阶段拒绝，后一种应阻止索引应用；失败可以留下包含资源 DID、游标、失败阶段和错误代码的记录，但不应推进受影响的同步游标。

10.6 版本新鲜度与同步游标

发布游标描述根平台发布事实在传播链路中的位置，同步游标描述发现服务节点已处理的位置，资源版本描述资源内容本身的版本，新鲜度描述材料从发布或接收到当前观察时刻的时间关系。它们分别服务于顺序、恢复、版本选择和延迟解释，不能用一个字段代替其它字段。

10.6.1 同步游标

同步游标由发现服务节点维护，用于表示该节点已经处理到的内容分发位置。游标推进必须以相应材料完成结构、哈希、证明和状态校验为前提；游标推进到某个位置不代表该位置之后的所有资源都已成功应用。

10.6.2 版本新鲜度

版本新鲜度应同时参考根平台发布游标、资源包版本、发布或更新时间、本地接收时间和索引应用时间。时间差用于解释传播延迟，不能单独决定版本优先级；同一 DID 的内容选择仍以可验证版本、哈希和根平台发布事实为准。

10.6.3 过期数据判断

发现服务节点应根据允许延迟、治理状态和资源生命周期判断数据是否过期。普通信息展示可以保留带新鲜度标记的旧快照；涉及撤销、暂停、节点授权变化或高风险调用前验证时，无法确认最新状态应暂停敏感动作，而不是继续使用未确认的旧状态。

10.6.4 缺口补偿

检测到游标缺口、批次序列不连续或资源材料缺失时，节点应暂停受影响范围的游标推进，按清单或更新接口补取缺失内容，并在重新校验后继续。缺口补齐前可以报告同步滞后，但不得把后续项目无依据地标记为已应用。

例如节点已应用游标 100，收到游标 102 而缺少 101 时，可以保存 102 的待处理材料并报告缺口，但本地“已应用位置”仍应保持 100。补取并验证 101 后，再按顺序处理 102；若 101 被明确拒绝，也应保留可追踪的拒绝记录，并依据实现定义决定是否允许游标跨过该项目。收到更大的游标值本身不是推进游标的充分条件。

10.7 初始同步与增量同步

10.7.1 初始全量同步

初始同步应先取得可验证的发布清单、起始游标和目标授权域，再按清单取得资源包及其证明。节点应逐项完成校验、落库和索引应用，并在整个范围完成或明确记录拒绝后，报告该范围的同步结果。

10.7.2 增量同步

增量同步从已持久化的同步游标或通知批次序列继续，获取其后的发布材料并按发布顺序处理。重复批次和重复资源包应幂等处理，新的游标只能在对应项目达到已应用或明确拒绝状态后推进。

10.7.3 同步确认

同步确认应至少区分已接收、已验证、已建立索引和对外可查。确认响应、日志和数据库记录应能够关联目标发现服务节点、序列范围、成功/拒绝项目、当前游标和最后错误，不能以 HTTP 请求成功代替内容收敛确认。

10.7.4 中断后恢复

节点重启或网络中断后，应从最后一个持久化游标或未完成批次恢复，重放必要材料并按幂等规则处理。若游标失效、清单发生变化或治理状态无法确认，应重新获取清单或进入待复核，而不是直接跳过缺失区间。

10.8 重试、退避与中断恢复

重试只针对可恢复的传输、超时、服务不可用或暂时性锁定失败。发布器和发现服务节点应保存任务或批次标识、目标游标、已处理项目、重试次数和最后错误，并使用退避避免持续冲击上游。签名无效、哈希不一致、资源类型错误和授权域不匹配属于材料或权限失败，应记录并停止对同一未改变载荷的无限重试。

重试记录至少应能回答三个问题：重试的是哪一个资源版本，失败发生在内容取得、校验、写入还是结果回报阶段，下一次重试依赖什么条件。批量处理时，应根据成功项目和失败项目分别更新结果；不能因为批次整体响应成功就重复应用已成功项目，也不能因为一项失败就丢弃其它项目的处理证据。重复投递同一任务应使用资源 DID、版本、哈希和发布游标进行幂等判断。

10.9 缓存行为与过期数据处理

10.9.1 浏览器或客户端缓存

浏览器或客户端缓存保存的是页面或客户端已经取得的公开材料、网络快照或资源摘要，不是根平台的权威发布记录。缓存键应包含接口范围、资源 DID 或页面数据版本等必要上下文；清空浏览器数据后缓存可以消失，服务端发布事实不受影响。客户端读取缓存时应带上取得时间、来源和新鲜度标记，避免把本地命中误显示为刚刚从网络确认。

10.9.2 节点侧缓存

内容分发平台和发现服务节点可以缓存已经通过相应校验的资源包或索引读模型。内容分发平台缓存的是可传播材料，发现服务节点缓存的是本地应用后的查询数据；节点侧缓存应保留资源版本、包哈希、发布游标和校验时间，更新时按可验证顺序替换。缓存不应绕过根平台可信发布证明、资源包哈希或当前治理状态检查。

10.9.3 旧快照优先展示

当页面或查询接口的新数据尚未取得时，可以先展示最近一次已保存且可识别来源的旧快照，同时标注快照时间、数据来源和可能的同步滞后。旧快照适合改善普通读操作的等待体验，不适合作为撤销、暂停、授权变化或高风险调用的实时依据。快照展示应与后台刷新状态分开，不能把旧数据的展示时间更新成当前确认时间。

10.9.4 后台刷新与失败降级

后台刷新成功后，客户端或节点应以新材料完成结构、哈希、证明和状态检查，再原子替换旧快照；刷新失败时保留旧快照并记录失败原因、最后成功时间和新鲜度。若失败涉及撤销或授权状态无法确认，应降低可用状态或暂停敏感操作，而不是无条件继续使用旧快照。刷新逻辑不能阻塞页面基本渲染，也不能在失败时清空已有有效数据造成不必要的空白。

10.10 传播可观测性与审计记录

传播审计应将资源 DID、包版本、包哈希、发布任务、发布游标、通知批次、目标发现服务节点、发送/接收/校验/应用时间、重试次数和错误原因关联起来。根平台和发布器应能说明哪些项目完成了内容分发，发现服务节点应能说明哪些项目被拒绝或仍待同步；这些记录用于追溯传播过程，不改变资源的原始证明。

对批量传播，应同时记录批次整体结果和每个资源项目结果。整体响应为成功不代表所有项目均已应用，部分成功也不应抹去已完成项目的证据。运维排查时可以沿 jobKey、请求 ID和发布游标关联根平台任务、内容分发平台历史和发现服务节点同步记录；这些字段用于追踪传播，不等同于资源控制方签名或治理授权。

对批量传播，应同时记录批次整体结果和每个资源项目结果。整体响应为成功不代表所有项目均已应用，部分成功也不应抹去已完成项目的证据。运维排查时可以沿 jobKey、请求 ID和发布游标关联根平台任务、内容分发平台历史和发现服务节点同步记录；这些字段用于追踪传播，不等同于资源控制方签名或治理授权。

10.11 发布顺序与冲突解决

传播顺序以根平台发布游标和通知序列为基础，资源版本选择以资源包版本、前序版本关系、包哈希和根平台可信发布证明为基础。相同材料的重复批次应幂等处理；同一位置出现不同哈希、旧版本试图覆盖新版本或前序材料缺失时，应暂停相关应用并记录冲突，不能按到达时间任意覆盖。

10.12 分发一致性与新鲜度保证

一致性指标应分别说明根平台已发布、内容分发平台可取得、发现服务节点已接收、已验证和已应用的范围；新鲜度指标应说明从哪个发布或接收时间点计算到哪个观察或应用时间点。指标必须附带样本范围、失败项目和授权域口径，不能以单个节点成功或缓存命中代表全网收敛。

10.13 部分失败与恢复语义

部分失败按资源项目和目标节点隔离处理。已完成校验和应用的项目可以推进自身状态，失败项目应保留独立错误、重试和缺失信息，不得因批次整体响应成功而跳过失败项目。恢复时先补齐缺失材料，再完成单项验证和落库，最后推进相应游标或记录明确拒绝；已应用项目不因同批次其它项目失败而回滚，失败项目也不能因旧快照可用而隐藏失败。

最终收敛要求目标序列范围内每个项目都达到“已应用”，或具有明确、可追踪的拒绝记录。恢复过程中若发现哈希、证明、生命周期或授权域发生变化，应重新进入相应校验流程；旧快照只能用于带新鲜度标记的有限读侧结果，不能掩盖撤销、暂停或授权变化。

参考来源