目录
周一 10:02，一封邮件。
标题：《关于部分功能升级调整的公告》。正文三段：为了提供更好的服务，我们将对系统进行架构升级；升级期间，部分功能将暂时下线；恢复时间另行通知。感谢您的理解与支持。
你关掉邮件，继续写代码。三年后，你想起那个功能，打开链接，页面还在 404。
这不是某一家的故事，而是一种文体的共同结局。功能下线公告有自己的语法：主语会消失，时间会模糊，原因会抽象，方向会被偷换。 学会读它，通常不是为了吐槽，而是为了在数据被删除之前，把自己的东西搬走。
一、公告的五种句法
1. 主语消失术
「经研究决定」「系统将进行升级」「相关功能将被调整」——三句话里都找不到一个能负责的人。
这不是中文特有的委婉。英文公告同样熟练地使用被动语态和名词化：a decision has been made、the service will be transitioned。语法的选择就是责任的分配：有主语，就要回答「谁决定的、为什么」；没有主语，就只剩一个既成事实。
2. 时间模糊术
「近期」「暂时」「稍后」「另行通知」是公告里的四个时间副词，它们共同的特点是：不能用来排期。
真正的计划通常有日期。没有日期的「暂时」，在项目管理里有一个更准确的名字：未排期。它可能真的只是暂时——故障恢复、合规审查、临时维护都属于这一类——但真的暂时会有状态页、有负责人、有下一次更新。什么都没有的「暂时」，只是一个礼貌的时态。
3. 原因抽象术
「业务调整」「架构升级」「聚焦核心业务」是三块万能挡箭牌。
它们并非全是假话，只是把一句很具体的话压缩成了一个名词短语。展开之后通常长这样：
- 这项业务不赚钱，或者成本高于收益；
- 维护它的人已经走了，没人愿意接手；
- 它和新战略不再一致；
- 继续维护它的安全成本超过了收入。
Heroku 在 2022 年关闭免费套餐时，用的是「把资源集中到 mission-critical 能力上」，同时明确提到了免费套餐带来的欺诈和滥用成本。这个说法至少承认了取舍：谁受益、谁承担成本。 相比之下，只写「业务调整」的公告，把取舍藏进了名词里。
4. 方向偷换术
2021 年，微软宣布 IE11 退役时，标题是：The future of Internet Explorer on Windows 10 is in Microsoft Edge.
这句话每个词都是真的，但它把「一个浏览器要停止支持了」说成了「它的未来在另一个浏览器里」。Google 关闭 Inbox 时也用了同样的手法：标题叫「Inbox is signing off」，正文重点放在「把 Inbox 最好的功能带进 Gmail」。
翻译过来是：产品停止，品牌保留，部分功能迁移，剩下的功能不保证。 这是一种高明的写法——它没有撒谎，只是把读者的注意力从「失去什么」引到了「去哪里」。
5. 责任外移术
「用户习惯发生了变化」「行业环境发生了重大变化」「使用率持续下降」——这类句子把公司的商业决定，描述成对客观规律的服从。
Google Reader 在 2013 年的告别信里就把原因写成「使用率下降」，同时表示公司要把精力集中到更少的产品上。这句话是诚实的，但它回答的是「为什么可以关」，不是「为什么必须关」。使用率下降的产品很多，关不关仍然是一个决定。
中文互联网最著名的一次公告修辞，大概要数 2010 年那封《致广大 QQ 用户的一封信》：「我们刚刚作出了一个非常艰难的决定。」这句话后来成了一个梗，因为它精准地展示了一种语法：决定已经做完了，艰难是留给你感受的。
二、逐条翻译
| 公告原文 | 可以怎么翻译 | 建议动作 |
|---|---|---|
| 暂时下线 | 没有回归日期，回来的概率不高 | 立刻导出数据 |
| 恢复时间另行通知 | 大概率不会有第二次通知 | 当作永久下线处理 |
| 停止新用户注册 | 第一阶段，通常还有 6–18 个月 | 不要在这里开新项目 |
| 进入维护模式 | 只修安全漏洞，不再加功能 | 开始规划迁移 |
| 架构升级 | 数据模型或 API 会变，旧数据不保证迁移 | 查兼容性和导出格式 |
| 与 XX 整合 | 独立产品消失，部分功能会被砍 | 确认功能保留清单 |
| 聚焦核心业务 | 这项业务不赚钱，或成本高于收益 | 找替代方案 |
| 交给合作伙伴运营 | 条款、隐私政策、价格都会变 | 重读服务协议 |
| 我们作出了一个艰难的决定 | 决定已经做完，不接受讨论 | 看补偿和退款条款 |
| 感谢您的理解与支持 | 公告结束，不做问答 | 去社区找迁移方案 |
最后一行需要补充一句：「理解与支持」不是请求，是通知。 它出现在公告末尾，作用是给整件事画句号，而不是开启一场讨论。
三、为什么公司要这样写
把所有模糊措辞都归因于「鸡贼」，有点偷懒。这些句子之所以稳定地出现，是因为公告同时要满足好几拨读者的需求。
法务和合同。 没有确定的日期，就不能在公告里写死日期。写死就是承诺，可能构成违约，也可能被拿去做集体诉讼的证据。「暂时」保留了后续解释的空间。企业客户通常另有 SLA 和通知期条款，所以同一件事会有两套措辞：给个人的公告，和给客户的合同附件。
商业。 公告的读者不只是用户，还有现有客户、潜在客户、投资人和员工。直接宣布「这个产品死了」，会加速用户流失、影响续费、打击团队士气。于是坏消息通常要配一个好消息：「同时，我们上线了新的体验。」
工程。 下线很少是一个开关，而是一条流水线：停止新注册 → 停止新内容写入 → 只读 → 停止登录 → 导出窗口关闭 → 删除数据。公告往往只写第一阶段，因为后面几阶段的日期还没有排出来。这不是故意隐瞒，很多时候写公告的人自己也不知道。
组织。 一份公告通常要经过产品、法务、公关、市场好几轮修改。每一轮都会拿掉一点具体信息，加上一点「感谢理解」。最后发出来的版本，往往是最不冒犯、也最不可执行的版本。
理解这些约束，不等于接受所有措辞。关键区别在于：模糊可以是策略，但不能是全部。 一份公告的诚实度，不取决于它用了多少形容词，而取决于它有没有给出可验证的承诺：日期、导出、迁移路径。
四、读公告的七个检查项
收到下线通知时，按顺序检查这七件事：
- 具体日期。 停止注册、停止写入、删除数据分别在哪一天？只有一个「近期」，就按最坏情况准备。
- 阶段时间线。 是停新用户，还是停所有写入？「只读」阶段通常是你最后的导出窗口。
- 数据导出。 有没有官方导出工具？导出格式是开放的 CSV/JSON，还是只有它自己认识的专有格式？截止日期是哪天？
- 退款与补偿。 按比例退款、代金券，还是「剩余时长折算到新产品」？后者通常意味着你被绑定到了下一个产品。
- 企业合同。 如果你用的是企业版，SLA、数据保留期、专属通知期是否适用？个人公告里的日期不一定适用于你。
- 机器可读信号。 API 有没有返回弃用信息？
Sunset和Deprecation两个 HTTP 响应头已经标准化，脚本可以直接监控。 - 归档与依赖。 文档、SDK、容器镜像、域名和证书还能拿到吗？很多服务关停后，官方文档最先消失，而你的构建脚本还在引用它。
第 6 项值得展开。Sunset 响应头由 RFC 8594（2019 年）定义，用来告诉客户端资源将在某个时间点停止可用；Deprecation 响应头由 RFC 9745（2025 年）定义，用来标记资源已弃用。两者可以同时出现：
HTTP/1.1 200 OKDeprecation: @1688169599Sunset: Sun, 30 Jun 2024 23:59:59 UTCLink: <https://developer.example.com/deprecation>; rel="deprecation"; type="text/html"Deprecation 的值是 Structured Fields 的日期（Unix 时间戳前加 @），Sunset 的值是 HTTP-date。这两个头最大的价值不是给浏览器看的，而是给监控脚本看的：你可以在服务真正消失之前，让 CI 或巡检任务替你发现它。
只发一篇博客公告、不返回任何机器可读信号的服务，等于把监控责任完全交给了用户的记忆。而用户的记忆，通常不如用户的待办列表可靠。
五、好公告长什么样
先看真实世界的通知期：
| 服务 | 宣布时间 | 停止或退役时间 | 提前量 |
|---|---|---|---|
| Adobe Flash | 2017-07-25 | 2020-12-31 | 约 41 个月 |
| Internet Explorer 11 | 2021-05-19 | 2022-06-15 | 约 13 个月 |
| Google Reader | 2013-03-13 | 2013-07-01 | 约 3.5 个月 |
| Heroku 免费套餐 | 2022-08-25 | 2022-11-28 开始关闭 | 约 3 个月 |
这四行数据说明一件事：通知期的长度，本身就是产品对用户依赖程度的一次定价。 Flash 需要给内容创作者留出重做整个网站的时间；IE11 需要给企业留出浏览器迁移的预算周期；一个免费 PaaS 套餐的迁移成本低，所以三个月看起来也「够用」。
如果你是发布公告的一方，下面这份清单可以直接抄：
- 一次给全时间线：停止销售、停止新注册、只读、停止写入、删除数据，各是哪天。
- 至少两次提醒：T-90、T-30、T-7。别假设邮件能送达，很多用户早就换了邮箱。
- 给导出工具和开放格式：CSV、JSON、标准压缩包。30–90 天的窗口是底线，不是美德。
- 给迁移映射表：不是「请使用新产品」，而是「旧功能的哪一项，对应新产品的哪一项；哪一项没有了」。
- 给机器可读信号：
Sunset/Deprecation头、changelog、RSS、状态页，至少有一个能被脚本订阅。 - 遵循公开的弃用政策：Kubernetes 的规则是 Beta API 在弃用后至少再服务 9 个月或 3 个 minor release（取较长者）；Stripe 的做法是固定 API 版本，升级由用户发起。两者都把「什么时候必须迁移」变成了可预期的事。
- 如果写「暂时」，就写清回归条件：什么情况下会回来、由谁决定、下一次更新是什么时候。否则「暂时」会变成一句没有期限的谎。
六、用户侧的操作系统
作为用户，你控制不了公告的措辞，但可以控制自己的暴露面。
订阅 changelog，而不只是订阅营销邮件。 下线公告通常发在开发者博客、changelog 或状态页，而不是「新品推荐」的邮件列表里。
定期导出，按 3-2-1 备份。 三个副本、两种介质、一份异地。对个人数据来说，这个规则听起来过度，但它的真正作用是让你在下线公告出现时，不需要在 48 小时内完成一次仓促的迁移。
优先选择开放格式和可自托管方案。 这不是要求所有服务都开源，而是说：当导出格式是标准格式时，你的迁移成本从「重做」降到了「导入」。
在「只读」阶段之前行动。 导出工具通常是最先失修的那部分——产品团队已经在做别的事了，没人会为一个月后就要删除的功能修 bug。
把每一次下线当成一次迁移演练。 真正需要练的不是导出按钮在哪，而是：你知不知道自己有哪些数据放在哪些服务里？哪些是唯一副本？哪些有合同保护？这些问题平时没人问，下线公告会替你问。
在欧盟，GDPR 第 20 条给了个人数据可携带权：你有权以结构化、通用、机器可读的格式取得自己的数据，并传输给另一个控制者。这是一条有用的兜底条款，但它兜的是「数据」，不是「服务」；它也不能替代你自己的备份。
写在最后
「暂时下线」是产品语言里的「我晚点回你」。
区别是，人还会回消息。
判断一份公告，不看它用了多少形容词，只看三样东西：日期、导出、迁移路径。 三样都有，哪怕它写「永久关闭」，你也可以体面地告别；三样都没有，哪怕它写「很快回来」，你也该开始备份。
毕竟，404 页面从来不会写「暂时」。
参考来源
- RFC 8594: The Sunset HTTP Header Field
- RFC 9745: The Deprecation HTTP Response Header Field
- Kubernetes Deprecation Policy
- Heroku’s next chapter（2022-08-25）
- The future of Internet Explorer on Windows 10 is in Microsoft Edge（2021-05-19）
- Adobe Flash update（2017-07-25）
- A second spring of cleaning（Google Reader 关闭公告，2013-03-13）
- Inbox is signing off（2018-09-12）
- GDPR Article 20: Right to data portability
- Stripe: API versioning and upgrades
延伸阅读：本博客还有两篇讲「同一类语言问题」的文章——《技术黑话词典：从「在我机器上是好的」到「这是个特性」》讲开发过程中的内部黑话，《技术写作心得：如何写出清晰的技术文档》讲怎么把这类信息写清楚。