企业官网建设流程全解析

• 文档

导读

本篇围绕 Rust RFC 仓库中编号 1985 的提案tiered_browser_support（分层浏览器支持），系统讲解 Rust 官方 Web 内容（rust-lang.org、crates.io、rustdoc 输出等）应当如何在浏览器兼容性与有限测试资源之间取得平衡。读完本文，你将完整掌握该 RFC 提出的"受支持 / 不受支持"两级浏览器清单、browserslist 格式的书写方式、配套的测试与 Bug 处理策略，以及支撑这些决策的真实流量数据与同类站点做法。

背景与动机：为什么 Rust 需要一份浏览器支持策略

RFC 1985 的提出有非常具体的现实触发点，而不是凭空的政策讨论。

一次 jQuery 移除引发的讨论。当时有一项从 rustdoc 输出中移除 jQuery 的 Pull Request（RFC 正文引用了它），其中大量讨论围绕"我们到底能做什么、不能做什么"展开，而这背后的根本问题是：Rust 社区从来没有就"官方 Web 内容需要支持哪些浏览器"达成过共识。

crates.io 的 flexbox 决策困境。crates.io 在不支持 flexbox 的浏览器（例如已停止支持的 Windows Phone 8.1）上无法正确显示。当时的维护者自行做出"不值得为修复这个问题花费社区时间"的决定，但没有人能确认这个取舍对社区而言是否正确——因为没有成文的标准可依。

测试资源是硬约束。以 Rust Web 内容维护者的人数，要在"所有浏览器、所有版本、所有设备"上维持相同行为是不现实的。crates.io 当时并未进行任何跨浏览器测试，仅有的 UI JavaScript 测试运行在 PhantomJS（一款基于 WebKit 的无头浏览器）上。由于缺少测试，社区实际上并不清楚当前 Web 内容的真实兼容范围，只能靠用户提交 Bug 报告来被动发现问题。

自动化测试平台同样受限。若要全面测试所有浏览器组合，要么需要拥有全部设备、操作系统、浏览器与版本，并有人力做手工测试；要么依托 BrowserStack 这类云测试服务。RFC 指出：BrowserStack 虽有为开源项目提供的免费计划，但并行测试数量不明确，且该平台并不支持所有平台——桌面 Linux 恰恰是 Rust 用户中一个不可忽视的群体，却不在其支持列表内。

基于以上背景，RFC 的目标是：像 Rust 编译器仅支持有限数量的目标平台并按支持程度分级一样，为官方 Web 内容建立一份分级的浏览器与版本支持清单。

适用范围：哪些内容属于"Rust 官方 Web 内容"

RFC 首先明确划分了策略的适用范围，避免边界不清。

正式纳入的官方 Web 内容：

• rust-lang.org
• blog.rust-lang.org
• play.rust-lang.org
• crates.io
• Rustdoc 输出（即rustdoc工具生成的文档页面）
• thanks.rust-lang.org

明确不纳入的内容：面向"正在开发 Rust 本身的人"的内容，例如 Rust Forge 与 rusty-dash。这类站点的受众是编译器与工具链开发者，与普通 Rust 用户的需求不同。

不完全受控但被用于官方或准官方内容的外部平台：

• GitHub
• docs.rs
• Discourse（用于 users.rust-lang.org 与 internals.rust-lang.org 两个论坛）
• mdBook 输出（用于 Rust 书籍与各类文档）

这类平台虽然托管着 Rust 官方或准官方的内容，但其浏览器兼容性基本不由 Rust 团队掌控，因此 RFC 将其单独列出，作为策略讨论时需要意识到但无法直接管理的部分。这提醒我们：任何浏览器支持策略都必须区分"我们自己的代码"与"我们借用的平台"。

核心设计：两级浏览器支持清单

RFC 基于 crates.io 的实际访问统计（详见后文数据章节），将浏览器支持划分为两级，并约定浏览器以 browserslist 格式书写。

受支持的浏览器（Supported browsers）

目标：确保 80% 用户的 Web 内容功能可用。

受支持浏览器的完整清单如下（browserslist 格式）：

last 2 Chrome versions last 1 Firefox version Firefox ESR last 1 Safari version last 1 iOS version last 1 Edge version last 1 UCAndroid version

逐条解读这条清单的含义：

• last 2 Chrome versions：最近两个大版本的 Chrome；
• last 1 Firefox version：最近一个版本的 Firefox；
• Firefox ESR：Firefox 扩展支持版（Extended Support Release，面向企业等场景的慢速更新渠道）；
• last 1 Safari version：最近一个版本的 Safari（macOS）；
• last 1 iOS version：最近一个版本的 iOS 内置浏览器；
• last 1 Edge version：最近一个版本的 Microsoft Edge；
• last 1 UCAndroid version：最近一个版本的 UC 浏览器 Android 版（UC Browser 在数据中占据约 1% 的份额，是榜单中唯一的移动端小众浏览器）。

支持承诺包括两条：

1. 自动化功能测试：通过 BrowserStack 之类的服务，对上述每个浏览器尽可能添加功能自动化测试；同时推动此前未做测试的 Web 内容（例如 rustdoc 输出）补上这类测试。
2. 高优先级修复：影响这些浏览器功能可用性的 Bug 会被优先处理。

不受支持的浏览器（Unsupported browsers）

目标：避免在老旧或小众浏览器的怪癖上耗费大量时间与代码复杂度。

"不受支持"的定义很干脆——凡未在上文列出的浏览器均属此类。对应的处理策略是：

• 不为其做自动化测试；
• 针对这些浏览器的 Bug 报告直接以WONTFIX关闭；
• 修复这些浏览器的 Pull Request 仅在评审者主观判断认为不会带来过多复杂度或维护负担时才接受。

这一设计的关键在于：分级不是"歧视用户"，而是把有限的维护精力显式地投放到能覆盖大多数用户的浏览器上，并让"不支持"成为一个明文的、可预期的决定，而不是每次都在讨论中临时拉扯。

与浏览器支持正交、必须坚持的原则

RFC 特别强调，以下原则与浏览器支持政策正交，无论最终采用哪种支持策略，都应持续追求（若读者认为其中任何一条不应被默认接受，RFC 欢迎提出异议，但明确这不是要取消这类支持）：

• 可访问性：遵循无障碍最佳实践，修复来自盲人用户的 Bug，并主动接触社区中的盲人用户以改进 Web 内容；同时应支持 lynx/links 这类文本浏览器，因为它们有时被配合屏幕阅读器使用。
• 色盲友好：遵循色盲设计最佳实践，例如用颜色传达的信息必须同时通过图标或文字传达。
• 移动端可用：遵循让内容在多种屏幕尺寸的移动设备上可用的最佳实践。
• 无 JavaScript 渲染：内容（尤其是 crates.io）应能在不执行 JavaScript 的情况下渲染；阅读之外的附加功能（如搜索、关注/取消关注 crate）可以依赖 JavaScript，但应尽可能使用链接和表单做渐进增强。

最后一条尤其值得注意：它把"渲染核心内容"与"增强功能"分层，与整个 RFC 的"分层支持"哲学一脉相承——在资源有限时，先保证核心体验，再做锦上添花。

数据依据：Google Analytics 浏览器使用统计

RFC 强调，CanIUse 等网站的统计数据反映的是大众用户的浏览器分布，而 Rust 的受众是开发者，两者并不相同，因此不能直接套用。为此，RFC 使用了 crates.io 与 rust-lang.org 上部署的 Google Analytics 数据：作者选择仅使用 crates.io 的统计，因为初步分析显示 rust-lang.org 前 90% 访问量的浏览器多样性低于 crates.io（即 crates.io 的分布更能代表更广泛的人群）。完整的分浏览器、版本、操作系统数据对访问者开放查阅；同时数据不含屏蔽了 Google Analytics 的用户。

以下为按浏览器及主版本聚合后的前 80% 会话数据（最近一个月的 crates.io 访问）：

从这张表可以得到几个有说服力的观察：

• Chrome 与 Firefox 占据绝对主导：仅 Chrome 三个版本（57/56/55/58）与 Firefox 四个版本合计就贡献了约 80% 的会话，这与"支持最近版本 Chrome + 最近版本 Firefox + Firefox ESR"的清单设计直接呼应。
• Firefox 45 是当时最新的 ESR（Firefox 52 也已发布并同样成为 ESR）；而 52 是当月多数时间的当前主版本，53、54 的少量早期使用者很可能是 Mozilla 员工——这说明"最近 1 个 Firefox 版本"叠加 "Firefox ESR" 可以覆盖表格中除 45 之外的绝大多数 Firefox 用户，而 45 恰好就是 ESR 本体。
• Safari 的碎片化明显：macOS 与 iOS 各自存在多个小版本，因此清单中分别保留last 1 Safari version与last 1 iOS version两条。
• UC Browser 值得单独保留：它以 1.02% 的份额挤入前 80%，说明在开发者用户中也存在非主流移动浏览器流量，这正是清单中last 1 UCAndroid version的来源。

同类站点的支持策略参考

RFC 还调研了"同领域"站点的浏览器支持声明，作为参照系：

• GitHub：支持当前版本的 Chrome、Firefox、Safari、Edge 与 IE 11；对 Firefox ESR 提供 best-effort（尽力而为）支持。
• Discourse：支持 Chrome 32+、Firefox 27+、Safari 6.1+、IE 11+、iPad 3+、iOS 8+、Android 4.3+（但未限定设备上的具体浏览器，且这些数字看起来已有一段时间没有更新）。

可以看出，主流技术平台普遍采用"支持较新的主流浏览器 + 对 ESR 尽力而为"的务实策略，与本 RFC 的提议方向一致。

落地与推广方式

RFC 提出，该策略应命名为"Rust Browser Support"，并采取与 Rust 平台支持分级（即编译器目标平台的分层）类似的方式，将支持分级列示在 Rust Forge 上。同时，应在开发 Rust Web 内容的地方以及 Rust FAQ 中链接到这份分层浏览器支持页面，让策略成为开发者与用户的共同预期。

从仓库实现角度看，这一"文档沉淀 + 入口链接"的落地方式与本仓库的运作机制是一致的：RFC 以 Markdown 文件形式存放于text/目录（本提案即 text/1985-tiered-browser-support.md），并可通过 generate-book.py 脚本被收集进 mdBook 生成的 RFC Book（脚本会把text/下所有.md章节与README.md、compiler_changes.md、lang_changes.md、libs_changes.md一起组织成src/SUMMARY.md），从而让策略文本成为可长期查阅、可链接引用的正式文档。这与 README.md 描述的 RFC 生命周期（合并后即为 "active" RFC，可在后续按需修订）相衔接。

代价与替代方案

主要代价（Drawbacks）

分层支持最直接的代价是：会把一部分不愿或无法使用现代浏览器的用户排除在外。这是显式选择，而非疏忽。

替代方案

RFC 列举了三类替代思路：

其一：调整清单参数。采用上文的分层结构，但换成不同的浏览器版本组合（例如扩大 Chrome 历史版本范围，或为 Firefox 保留更多版本）。这是同一框架下的参数微调。

其二：调整支持程度。保留上述浏览器清单，但改变每一级的支持力度（例如对"不受支持"浏览器也保留部分 Bug 响应义务）。

其三：维持现状（不设立官方层级）。这是 RFC 最想避免的路径：继续让影响浏览器支持水平的讨论和决策零星发生，却没有共识性指南可供参考；继续不在多浏览器下测试、依赖用户 Bug 报告，由做事的人临时（ad-hoc）决定一个修复值不值得做。而"支持所有浏览器、所有配置"是另一个被明确考虑的极端方案：尽最大能力测试所有组合，仍依赖社区报告来覆盖部分配置，但不再因为复现所需的浏览器或版本而关闭任何 Bug 或 PR。RFC 的立场是：这两个极端（无政策 / 全支持）要么让决策失控，要么让维护成本失控，分层方案是两者的折中。

遗留的未决问题

RFC 收尾时留下了两个需要进一步讨论的问题：

1. 官方 Web 内容清单是否完整——是否还有应当纳入本策略的其他官方 Web 内容被遗漏？
2. rustdoc 能否加入浏览器测试——给 rustdoc 添加浏览器测试是否可行，还是会让本就漫长且偶发失败的 rustc 构建雪上加霜？

第二个问题尤其具有现实意义：rustdoc 输出被列为受本策略约束的官方内容之一，但其构建与测试路径与 rustc 编译器深度耦合（本仓库中 text/2963-rustdoc-json.md、text/3958-rustdoc-texmath.md 等 RFC 也从不同侧面体现了 rustdoc 作为持续演进的输出面），如何在不拖垮编译流程的前提下为其增加浏览器层面的回归测试，是一个需要权衡的工程问题。

延伸阅读：与仓库内其他 RFC 的关联

本 RFC 的"分层支持"思想并非孤立存在。仓库中同样采用分层思想的代表作是 text/2803-target-tier-policy.md（Target Tier Policy）：它把 Rust 编译器支持的目标平台分为 tier 1 / tier 2 / tier 3，并分别规定 CI 保证与维护义务（tier 3 仅存在于代码库、可能无法构建；tier 2 保证可构建；tier 1 保证可构建且通过测试）。RFC 1985 的正文在 Summary 中即引用了该领域的前身——Rust Forge 的平台支持页面，并在 "How We Teach This" 一节明确表示希望浏览器支持分级能以类似 Rust 平台支持分级的方式呈现。两份 RFC 共享同一方法论：在人力、时间与测试资源有限的前提下，用显式分级替代无边界承诺，让"支持到什么程度"成为可预期、可评审的契约。

如果你想进一步了解本 RFC 提案本身，可以直接阅读仓库中的 text/1985-tiered-browser-support.md 原文；了解 RFC 提案的撰写与评审流程，可查阅 README.md 与 0000-template.md（RFC 模板）。

• 文档