摘要

  • RFC 9745 的 Deprecation 表示某个资源将被或已经被弃用，RFC 8594 的 Sunset 表示该 URI 预计何时不再响应；两者默认只针对返回它们的资源，而且都是提示，不是迁移完成证明。
  • 一份客户端迁移切换记录应把所见响应与明确范围、替代目标、调用方负责人、使用证据、兼容测试、例外决定、回退条件和关停后的观察连接起来。

分析

最容易被忽略的退出通知，往往藏在一条完全正常的响应里。业务请求成功，数据格式也没有变化，只是响应头新增了 Deprecation 日期。服务器团队已经做了一件正确的事：把资源的生命周期状态暴露给消费者。可是，客户端库可能根本不保留陌生响应头，监控可能只统计错误率，真正负责该应用的人也可能从未看到这条信息。

所以，“通知已经发出”和“迁移已经受理”是两个不同事实。

RFC 9745 给第一个事实规定了互操作形式。Deprecation 的值是结构化日期。日期在未来，表示计划从何时起把当前资源视为弃用；日期在过去，表示这个状态已于何时生效。标准同时划出一条重要边界：宣布弃用不会改变资源本身的行为。它仍可继续返回同样的成功结果。

该 RFC 还定义了 deprecation 链接关系。供应方可以用它指向补充材料，说明弃用政策、时间表、替代资源或迁移方法。这里的能力不是完整性保证。IANA 登记让关系名有了共同含义，却不会替某一个链接证明内容仍然有效、作者仍有权限，或文档已经覆盖每一种客户端条件。

RFC 8594 的 Sunset 回答的是后一个阶段：某 URI 预计从何时起不再响应。这个日期同样只是提示。它不保证资源一定存活到该时刻，也不保证一到时刻就消失，更不规定之后会返回错误、重定向，还是完全无法连接。如果它与 Deprecation 同时出现，RFC 9745 要求 Sunset 不得早于弃用日期。正确的先后顺序可以排除配置矛盾，却不会凭空生成迁移方案。

默认范围比人们想象得窄

两个响应头默认都只描述当前响应所对应的资源。服务方可以另外声明扩大范围，例如主页上的日期适用于某个版本下的所有路径。但不知晓这条本地规则的消费者看不见扩大后的含义。只调用深层路径的程序也可能永远遇不到主页上的通知。

这意味着抓取到一个响应头，只能证明某个 URI 在某个时刻发出了某个值。它不能自动证明所有方法、区域、账号和调用方都在同一退出范围。反过来，某条路径没有响应头，也不能证明它必然不受其他公告影响。

两份 RFC 都把这些信息当作可选提示，客户端必须能够在提示缺席时继续合理运行。这不是削弱标准，而是承认开放系统里的观察面不完整。迁移治理需要在记录中保留精确 URI、观察时间、响应指纹、字段值，以及谁有权把范围从单个资源扩大到整套服务。

发现替代地址不等于获准自动切换

一份迁移说明可以大幅减少不确定性，但不能因为通过标准链接被发现，就被当作无人审核的生产指令。RFC 8594 特别提醒，可机读的迁移信息可能引发大规模资源身份变更；消费者需要核验真实性、准确性和适用范围，防止某项政策把不归它管辖的资源带走。

真实系统里，地址变化往往只是表面。新主机可能采用不同的身份签发方、令牌受众、权限范围和限额；请求字段看起来相似，却可能改变默认值；失败重试可能从幂等变为重复执行；数据保存地点可能跨越法域；一个适用于读取请求的重定向，可能使带签名的写请求失效。

这些问题不应被塞进响应头标准里。标准负责表达生命周期意图，客户端与服务端共同负责证明一次具体切换是否安全。把两类责任混为一谈，要么会把协议做得无法使用，要么会把迁移变成盲跳。

建立客户端迁移切换记录

缺少的治理对象不必庞大。它可以是一份可审阅、可更新的客户端迁移切换记录。

第一部分固定信号证据：规范资源 URI、观察时间、响应指纹、Deprecation 值、Sunset 值，以及当时可见的 deprecation 和 sunset 链接。它明确写出适用范围及范围声明者。若不同页面或团队对范围说法不一致，记录保留分歧，不能用“全服务”三个字把问题抹平。

第二部分描述替代目标。除了新 URI 或版本号，还要逐项记录请求与响应语义、认证、授权、令牌受众、限额、顺序保证、错误行为、数据保留和区域可用性。公告文档证明供应方说过什么；受控试运行证明某一版本的客户端在某一组条件下看见了什么。两者应分别留证。

第三部分列出已知客户端。每个调用方都要有负责人、关键程度、最后一次观察到的使用、观察来源、迁移状态和下一个决策日。使用量为零也必须注明视野限制：缓存、中间代理、季度任务、灾备环境或独立地区可能不在当前日志里。没有看到不等于确认不存在。

第四部分管理例外。替代版本缺少功能、数据位置尚待批准、第三方发布周期被锁定，都可能构成暂缓理由。但每项例外必须有决策人、原因、临时缓解措施和到期日。“仍在使用旧版”本身不是例外依据。

最后一部分才是切换授权。它写明先行客户端、成功指标、停止条件、回退目标、触发器和最后可安全回退的时刻。切换后，还要记录旧资源实际返回了什么。服务继续运行，是需要解释的新事实；提前退出，是需要复盘的偏差；两者都不能倒过来改写原公告。

一项迁移有多只时钟

弃用日期表示供应方对资源地位的判断。Sunset 表示对未来可用性的预期。每个客户端有自己的目标日期，每项例外有自己的失效日期，回退能力也有技术截止点。真正关停则是事后才能确认的事件。

如果把这些日期压缩成一个倒计时，权责就会消失。团队可能因为“日期到了”而过早关停，也可能因为“还能访问”而永久拖延。供应方可以推迟 Sunset，但仍不再推荐旧资源；低频客户端也可能在关停后才暴露。正确做法是并列这些时钟，并为每一个标明可修改者和修改后果。

来源

  1. RFC 9745 — The Deprecation HTTP Response Header Field
  2. RFC 8594 — The Sunset HTTP Header Field
  3. IANA 链接关系类型登记表