发布时间：2025 年 11 月 7 日
为日本各地超过 38,000 家企业客户管理浏览器兼容性并非易事。当 Kintone 每天为超过 150 万个应用提供关键业务运营支持时，每个浏览器支持决策都至关重要。
Cybozu 是日本一家领先的群件公司，面临着一个根本性的挑战：如何在产品中保持一致的网络标准，同时避免自定义浏览器支持矩阵带来的维护负担。
解决方案就是：采用 Baseline 作为开发标准，这一举措彻底改变了他们采用 Web 平台功能的方式！
挑战：浏览器支持，但需要猜测
在推出 Baseline 之前，Cybozu 根据访问日志和手动版本跟踪来维护自己的浏览器支持标准。他们的标准是支持覆盖前 98% 访问日志的浏览器，而使用超出该阈值的浏览器的用户会看到浏览器更新提示。
每个季度，Cybozu 的工程团队大约花费 1 小时来更新条件。不过，将标准集成到开发团队的过程并不顺畅，经常会遇到以下问题：何时可以使用新的 CSS 功能？何时可以移除新 JavaScript API 的 Polyfill？那么，哪些功能现在可以使用？
Cybozu 的自定义条件不仅难以维护，对开发者来说也不够实用。他们还意识到，基于用户代理检测和手动版本跟踪进行构建无法跟上现代网络的发展速度。
User-Agent 字符串是否可靠
Cybozu 之前的做法是从 User-Agent 字符串派生出浏览器名称和版本，然后将这些结果汇总为“用户”数据，但这真的能反映用户的真实情况吗？
User-Agent 是一个 HTTP 请求标头，任何客户端都可以声称自己是任何内容。产品访问日志包含来自机器人、抓取工具、攻击者和其他来源的大量请求。有些客户端会出于各种目的（例如漏洞扫描）有意发送旧的 User-Agent 字符串。因此，访问日志无法代表应支持的用户。
User-Agent 无法反映可用功能
浏览器版本不与功能对应。同一版本号可能具有不同的功能，具体取决于渠道（稳定版/Beta 版/开发者版/Canary 版）、功能标志、Finch 实验或企业政策等。此外，不同浏览器实现功能的时间表也各不相同。例如，CSS 嵌套功能在 Safari 16.5（2023 年 5 月）中发布，但在 Chrome 112（2023 年 4 月）中发布。User-Agent 字符串并不表示功能可用性。
自行负责支持浏览器版本
浏览器更新不仅包含新功能，常规浏览器版本还包含重要的安全补丁和 bug 修复，以及新功能。如果支持过时的版本，那么避免使用新功能就不是唯一的问题，同时也是一项直接影响用户安全性的决定。在企业环境中，部分用户可能会面临合理的限制。例如：
- 组织可能制定了严格的浏览器政策，禁止更新。
- 旧版硬件不支持更新现代浏览器。
- 受监管行业中变更审批流程缓慢的用户。
不过，支持这些用户也意味着他们仍会面临安全风险。
如果因利用旧浏览器版本中的已知漏洞而发生安全事件，那么“此浏览器受支持是因为用户要求支持”这种说法就无法作为合理的解释。如果攻击蔓延到其他正确维护更新浏览器的用户，那么开发者和其他项目利益相关者将因未能停止对不安全浏览器的支持而承担责任。
Cybozu 意识到，这种方法会给大多数保持浏览器更新的用户带来风险。仅根据日志计数来支持浏览器缺乏适当的安全验证。这不仅意味着用户无法使用新功能，还意味着我们未能尽到保护用户的责任。
问题从“有多少用户在使用此版本？”转变为“我们是否应该根据浏览器版本为用户提供支持？”
为什么基准是 Cybozu 的正确答案
Cybozu 需要一种新方法，不仅要解决维护浏览器支持标准的运营开销，还要解决旧方法中的根本缺陷。基准正是 Cybozu 所需的。
由外部维护的不断变化的条件
Baseline 不会每季度手动重新评估浏览器版本，而是提供由 W3C WebDX 社区组维护的动态目标，而不是由个别公司做出任意决定。这意味着，这些标准会根据浏览器供应商和标准机构的意见自动演变。
Kintone 无需再自行管理版本阈值，基准会自行演变，无需采取任何行动。功能的基本状态可明确解答可用性问题，并且随着平台的发展，答案也会自行更新。
功能级精确度
Baseline 采取的方法与尝试跟踪单个浏览器的情况截然不同。
“Baseline 广泛可用”表示主要浏览器支持的 Web 功能已满 30 个月或更长时间。此时间范围的确定依据是“开发者信号、浏览器发布采用率随时间的变化、高总市场份额支持的估计值以及 WebDX 社区组的最佳判断”。通过设置此阈值，Baseline 可免除跟踪无法观测到的个别浏览器情况的任务。
借助 Baseline，开发者可以直接了解特定功能在各个浏览器中的可用性。“我们可以使用 CSS 容器查询吗？”现在可以回答这个问题了。开发者可以立即在 MDN 或其他文档中查看基准状态，而无需交叉引用兼容性矩阵。
从设计上保证安全
通过采用“广泛可用的基准”作为标准，Cybozu 将支持政策与自然关联的浏览器供应商支持生命周期保持一致。仍在积极维护的浏览器将支持所有“广泛可用”的功能，同时还会收到重要的安全更新。
基于访问日志的标准可能会使支持服务依赖于过时的浏览器，从而降低用户更新浏览器的意愿。采用基准后，我们不仅可以放心地使用新功能，而且随着 Web 平台的发展，使用旧版浏览器的用户自然会遇到需要更新的情况。
Baseline 并未明确排除存在安全漏洞的浏览器，而是通过自然激励措施促使用户及时更新浏览器。
采用 Baseline
采用 Baseline 需要从 Cybozu 的旧版版本管理模式转变。这意味着 Cybozu 需要确信 Baseline 在运行过程中不会出现重大缺陷。了解该功能会影响多少用户对于企业级采用至关重要。
Google Analytics Baseline 检查器是一种工具，可分析从 Google Analytics 导出的数据，以显示有多少百分比的用户支持每个 Baseline 年份的功能。此工具可帮助 Cybozu 检查选择基准目标对用户的实际影响。运行基准检查器后，Cybozu 发现了一些令人惊讶的结果：
基准检查工具显示，98.8% 的 Cybozu 用户使用的浏览器支持“广泛可用的基准”目标。这比 Cybozu 之前至少 98% 用户的内部标准覆盖范围更广。根据所提供的数据，我们可以分析以下三个关键点：
- 之前支持的浏览器不受影响。
- 之前不受支持的浏览器：约占 0.8%，符合“基准广泛可用”标准，但不再显示浏览器更新提示。
- 其余浏览器会像以前一样继续收到浏览器更新提示。
值得注意的是，这意味着可以消除假正例，即之前有大约 0.8% 的用户虽然使用的是功能强大的浏览器，但却不必要地看到了警告。与此同时，也不会因警告之前受支持的用户而引入假负例。
有了这些数据，Cybozu 就可以放心地采用“Baseline 广泛可用”作为目标。
Baseline 的实际影响
将 Baseline 作为政策采用是一回事，但要使其正常运行，还需要构建工具和流程。有必要确保开发者不会在未手动检查基准状态的情况下意外使用不受支持的功能。
基于 ESLint 配置的静态分析
@cybozu/eslint-config 是 Cybozu 产品中使用的基于 OSS 的配置。它从 css-baseline 预设开始支持，该预设会在构建时根据 Baseline 检查 CSS 功能：
// eslint.config.mjs
import cybozuEslintConfigBaseline from '@cybozu/eslint-config/flat/presets/css-baseline.js';
export default [
...cybozuEslintConfigBaseline.map((config) => ({
...config,
files: ['**/*.css']
})),
];
当开发者使用尚未达到“Baseline 广泛可用”阶段的功能时，会立即收到来自 ESLint 的反馈：
这样可以防止兼容性问题影响生产。开发者可以在开发过程的早期做出明智的决策：要么等待该功能广泛可用，要么在确切了解哪些用户会受到影响的情况下实现渐进式增强。（详细了解 ESLint 的 CSS 和基准支持。）
配置转译器以定位到 Baseline 广泛可用
现代构建工具已开始支持将 Baseline 作为目标。例如，Vite 会自动以生产环境中的“基准广泛可用”为目标，而无需额外配置。Browserslist 现在也支持 Baseline。
通过使用各种编译器设置，我们可以确保仅在必要时对 JavaScript 和 CSS 进行转译，从而避免对已广泛支持的功能进行不必要的转换和填充。
为用户反馈消除手动维护条件和浏览器检测系统
最大的维护优势在于无需再手动跟踪浏览器版本。现在，Cybozu 不再需要每季度召开会议来讨论要支持哪些浏览器版本，而是依靠公开维护的 @web-platform-dx/baseline-browser-mapping 软件包来解答这些问题。
Cybozu 还构建了自动浏览器检测功能，以便向使用过时浏览器的用户显示升级提示。
其浏览器检测功能直接从 @web-platform-dx/baseline-browser-mapping 软件包中提取兼容的浏览器版本。
此流程会在我们的 build 流程期间运行，并生成在所有产品团队之间共享的警告横幅。随着“广泛可用的基准”窗口的移动，纳入的浏览器越来越新，我们的系统会自动检测到这些变化，无需人工干预。
简化沟通
最重要但出乎意料的优势之一是 Baseline 如何简化了跨团队沟通。以前，浏览器兼容性讨论需要特定于公司的领域知识，例如我们支持哪些浏览器、哪些版本，以及现在有哪些功能可用。新员工需要时间来了解我们的内部标准。借助 Baseline，我们现在可以参考网络社区广泛认可的相同兼容性标准。
这也有助于在我们的工程团队内部以及与更广泛的网络社区之间建立共同的词汇。在讨论功能采用情况时，每个人都参考来自同一来源的相同数据，从而无需解释内部政策或在不同的兼容性框架之间进行转换。
开发工具也紧随其后：Visual Studio Code 和 Chrome 开发者工具中的样式面板现在可以直接显示 Baseline 兼容性信息。开发者不再需要不断查看 MDN 或我可以使用来验证某项功能是否可以安全使用。该工具会立即告知他们。
让产品能够自信地为所有人服务
借助 Baseline，我们可以从根本上改变对浏览器兼容性的看法，将其从需要管理的负担转变为值得信赖的基础。我们的实施策略以每个阶段的自动化为中心：
- 开发时反馈：静态分析和基准状态卡片。
- 构建时验证：转译器会自动以 Baseline Widely available 为目标平台。
- 运行时检测：针对使用
baseline-browser-mapping的不受支持的浏览器显示面向用户的警告。 - 持续更新：与基准数据自动同步，无需手动维护。
结果不言而喻：
- 浏览器版本维护时间为零小时。
- 超过 98.8% 的用户覆盖率通过功能级确定性得以维持。
- 即时、自发的常见问题解答，可回答“我们可以在此浏览器版本中使用此功能吗？”这一问题
- 工程团队之间共享词汇。
- 更清晰的功能采用路径会提示团队讨论新功能集成和移除 Polyfill 的时间（如有必要）。
对于考虑采用基准的组织，了解这种转变将如何影响用户至关重要。借助 Google Analytics Baseline 检查器等工具，您可以更直接、更清晰地进行这种衡量。当您对数据有信心并决定采用 Baseline 后，便可使用不断壮大的 Baseline 生态系统来整理您的开发工作流程。
与过去相比，Web 平台的功能更强大、更一致、更可靠，并且发展速度更快。借助 Baseline，我们可以放心地在生产环境中使用该功能。
资源
- 日语原文：プロダクト開発の基準に Baseline を取り入れるまで - Cybozu Inside Out
- Cybozu ESLint 配置：GitHub 上的
@cybozu/eslint-config - Google Analytics Baseline 检查器：Google Analytics Baseline 检查器
- 基准浏览器映射：
@web-platform-dx/baseline-browser-mapping - 了解 Baseline：MDN 上的 Baseline