配置中心客户端为什么要上报版本？

简化版

服务端发布成功不能证明每个客户端已经应用。客户端上报实际版本、加载结果和时间，平台才能计算收敛率，发现离线、拉取失败、解析失败与灰度错配。上报提供状态证据，不能用多数上报反过来决定配置真值。

上报至少关联应用、环境、租户、配置标识、实例、期望版本、实际版本、应用时间和结果码。客户端在启动加载、成功切换、加载失败和周期心跳时上报。服务端按当前目标健康实例集合计算收敛率，并单列失败、未知和离线。

实例 ID 等高基数字段进入有 TTL 的状态表，聚合比例进入时序监控。配置内容和秘密不得上报。灰度扩量需要收敛率、业务指标和最小观察时间同时达标。

链路包括存储提交、通知、客户端拉取、解析和动态应用。任何一步都可能失败，服务端无法从“通知已发”推导“业务已用”。客户端上报补齐数据面的真实状态。

期望版本表示应该是什么，实际版本表示现在是什么；两者之差就是治理对象。

启动代次可以区分同一地址上的进程重启。上报接口需要认证授权，防止跨租户伪造状态。

启动加载后上报一次，每次应用成功或失败时事件上报，无变更时周期心跳。三种时机结合，才能发现进程消失和持续失败。

{
  "config": "prod/order/timeout",
  "expectedVersion": 82,
  "appliedVersion": 81,
  "status": "VALIDATION_FAILED"
}

全量变更时用批量、压缩和抖动避免上报风暴。

目标 100 个健康实例，90 个成功、5 个失败、5 个未知，收敛率是 90%。不能排除未知后把数字美化为 94.7%。已缩容实例及时移出目标集合，灰度目标则保存规则快照。平台同时展示成功、失败、未知、离线，而非只有一个百分比。

失败码区分下载超时、未授权、摘要错误、格式解析、业务约束和监听器异常。只报 FAILED 无法指导处置。错误详情应限长并脱敏。应用失败时 appliedVersion 必须保留旧版本，不能上报“收到”的新版本。

发布序列最好单调递增。回滚创建新版本 83，其内容引用历史版本 79，而不是让版本号退回 79。

v81(content A) -> v82(content B) -> v83(content A, rollback)

这样客户端能判断通知新旧，审计链也不会断裂。

10 万实例每 30 秒一次约为 3333 次/秒，需要批量汇聚、分区和过期清理。实例明细进入状态存储，收敛比例进入监控，避免高基数标签拖垮时序库。控制面故障时客户端限量重试上报，但不能阻塞业务读取配置。敏感内容、口令和低熵摘要都不应进入上报。