# example.com 何时成了你的健康检查端点？

**Summary:** example.com 现在将简短的初始页面与完整的多语言说明分开加载。我会将其尽力而为的 HTTP 服务排除在应用健康决策之外，并为每种探测选择适合其目的的目标。

- Canonical: https://markhuang.ai/zh/news/example-com-never-agreed-health-check
- Language: zh-CN
- Author: [Mark Huang](https://markhuang.ai/about)
- Published: 2026-10-06
- Section: News
- Tags: example.com, IANA, 健康检查
- Source: [DebugBear](https://www.debugbear.com/blog/example-dot-com-redesign-history)
- License: https://creativecommons.org/licenses/by-nc/4.0/

---

![一本打开的参考书，空白页面连接着密集缠绕的网络线缆](https://cdn.markhuang.ai/news/example-com-never-agreed-health-check/hero.webp)

*一个文档示例可能通过一次次便利的连接，变成实际运行的依赖项。概念性插图。*

example.com 换了新面貌，但我更在意其中的警告。[DebugBear 的改版历史](https://www.debugbear.com/blog/example-dot-com-redesign-history)提到，该网站在 2026 年 9 月 28 日从静态英文页面扩展到了六种语言的说明。信息依然直白：可以在文档中使用该域名，但不要依赖其网站进行测试或监控。

这次改版让我重新审视自己的健康检查。我会在示例 URL 中保留 example.com，但不再拿它的 HTTP 可用性来判断应用是否健康。一个专用于示例的域名，并不承诺会一直响应请求。

流量数据解释了运营方为何在意。在[《Being Exemplary》](https://kimdavies.com/being-exemplary)一文中，Kim Davies 提到 example-domain 服务在 2026 年 9 月的一周内收到了约 500 亿次请求。他报告的是涵盖多个示例域名的服务总量。一个本为文档而设的网站，却背上了远超其设计初衷的工作量。

## 动画效果早已改变

DebugBear 描述过一个版本：每五秒轮换一次语言，字符逐个淡入。这段历史很有价值，但在我 10 月 6 日查看源码时，线上实现已非如此。

[当前的 HTML](https://example.com)只包含简短的英文说明，并加载一个独立的[JavaScript 文件](https://example.com/s.js)。该脚本添加其余五种翻译，根据浏览器的语言偏好将支持的语言置顶，并将所有翻译保留在页面上。文中描述的自动轮换效果并不存在。

我更喜欢这种安静的安排。需要查看说明的人应该能按自己的节奏阅读。这也表明，一旦健康检查绑定到这类页面的确切内容，就很容易过时——维护者随时可以调整说明内容。

## 为何说明内容放在独立文件中

DebugBear 文章中引用的 IANA 声明解释了这种拆分：大部分流量来自自动化程序，通常不会获取 JavaScript 文件，因此较小的初始页面能减少这些请求所需的数据量。人类访客仍可通过浏览器获取完整说明。

Davies 将此视为一次实验，并表示运营方会持续监控。他还提醒，相关成本是压缩后的传输数据量，而非源文件中的字符数量。两种解释都未提供改版前后的带宽节省实测数据。我会采信这一设计理由，但对具体收益持开放态度。

我很欣赏这种将更多说明内容留给真正需要的读者的做法。该设计适应了人类与自动化调用者的不同行为模式。但这些调用者是否该出现在这里，却是另一个问题。

## 熟悉的端点是个诱人的捷径

我能理解为何有人会选择 example.com 作为快速的外部目标。它容易记住。在[Hacker News 的讨论](https://news.ycombinator.com/item?id=49971921)中，有评论者提到用它触发强制 Wi-Fi 门户。还有人认为，无论运营方本意如何，这些域名事实上已演变成一种服务。

这种预期不难理解。持续可用会让捷径显得可靠。但在让产品依赖它之前，我会先确认运营方承诺保留哪些行为。

[IANA 的指引](https://www.iana.org/help/example-domains)明确划定了边界：该 Web 服务仅为尽力而为，不适用于支撑生产应用，也不应成为必需的 HTTP 依赖。域名保留是为了保护其在示例中的使用，而非将响应体变成 API 合约。

这种担忧早于此次改版。[1999 年 6 月发布的 RFC 2606](https://www.rfc-editor.org/rfc/rfc2606)就警告过，测试软件可能逃逸出测试环境，文档示例也可能最终运行在真实的互联网上。保留示例域名解决了命名混淆问题，但并未使对其服务器的任意使用都变得合理。

## 我会改变健康检查的结论范围

如果健康检查请求 example.com 并收到响应，唯一能得出的结论是：该请求得到了答复。这本身无法证明我的应用后端是否可用。同样，若请求失败，也无法将故障归因于我的应用。

我会从每个探测应支持的结论出发。对于应用健康决策，我希望使用自己控制的、有文档记录的端点，其响应能代表我正在检查的依赖项。对于外部连通性探测，我会刻意选择专为此目的设计的目标，并明确其失败对产品的影响。

即便如此，我仍需谨慎对待自有端点能证明的内容。局限于自身基础设施的检查无法回答所有关于访问公网的问题。改进在于把这些问题拆开，避免无关的外部故障自动变成应用宕机。

这正是我从此次改版中得到的启示。多语言翻译有助于说明 example.com 的用途，更小的基础页面则应对了涌入的流量。而我在自己的软件中要做的改变更简单：把示例留在文档里，给健康检查分配一个职责明确的端点。