尽管链接是文档的重要组成部分，但它们也有其自身的维护成本。
我们采用了一些策略来简化链接维护。
共有 3 种类型的链接：
- 外部（External）：指向其他资源的链接，例如 www.cloudflare.com。 ↗
- 内部（Internal）：指向文档中其他页面的链接，例如 Workers。
- 锚点（Anchor）：指向文档中其他页面特定部分的链接，例如 代理记录。
对于每种类型的链接，我们都会思考其体验的几个不同方面：
- 外部链接：
- 真实信源：另一个网站。
- 断开原因：另一个网站更改了其内容。
- 链接断开后的用户体验：另一个网站上的
404页面。
- 内部链接：
- 真实信源：您自己的网站。
- 断开原因：您自己的网站更改了其内容。
- 链接断开后的用户体验：您自己网站上的
404页面。
- 锚点链接：
- 真实信源：您自己的网站。
- 断开原因：您自己的网站更改了其内容。
- 链接断开后的用户体验：您自己网站的页面加载完成，但内容可能在页面更下方，或者已被移动到另一个页面。
在这三种链接类型中，只有内部链接：
- 发生在对您网站内容进行修改的上下文中。
- 普遍会导致糟糕的用户体验（
404页面）。 - 在当前上下文中极易进行审计。
基于这些原因，如果存在损坏的内部链接，我们会选择使构建失败。在我们的具体实现中，我们依赖 Nimbus ↗ 的 nimbus/internal-link 静态检查（lint）规则 ↗，该规则配置在 astro.config.ts ↗ 中。
对于此类链接审计，我们还做出了两项有意为之的决定：
- 绝对链接而非相对链接：我们强制使用绝对链接（
/style-guide/how-we-docs/metadata/），如果使用相对链接（../metadata/）则会导致构建失败，以避免未来耗时的维护。这一决定也有助于查找/替换工作以及未来的平台迁移。 - 无重定向：我们在评估链接时不会考虑重定向。既然我们拥有当前的真实信源，我们就应该充分利用该源（这也有助于我们避免重定向链和未来的维护负担）。
尽管外部链接损坏对用户体验不好，但它们并不会在您网站内容发生修改的上下文中发生变化。此外，外部链接检查可能非常耗时且容易出错，这可能会减慢贡献速度。
我们使用外部 SEO 工具来帮我们标记这些损坏的外部链接，并根据需要进行处理（而不是因为它们而导致构建失败）。
锚点链接出错的后果不像内部链接那样严重。如果您的锚点链接损坏，用户要么需要手动滚动到标题，要么（在某些情况下）转到另一个页面。
由于这些特点，我们使用 htmltest 库运行定期的后台检查 ↗来标记损坏的锚点链接。