浏览器 Baseline 信息如何辅助前端兼容决策

前端团队遇到“这个 CSS 或 Web API 现在能不能用”时，Baseline 最适合做第一轮筛选：它把跨浏览器支持压缩成 Limited availability、Newly available 和 Widely available 等可读信号，帮助团队快速缩小调查范围。但 Baseline 不是对每个站点的兼容保证，最终仍要看真实用户浏览器、业务关键路径、WebView 差异和功能失败后的替代方案。

Baseline 先解决的是“要不要继续查”

Baseline 由 WebDX Community Group 维护，核心浏览器集合包含桌面和 Android 上的 Chrome、Edge、桌面和 Android 上的 Firefox，以及 macOS 和 iOS 上的 Safari。一个特性尚未在核心浏览器形成共同支持时，通常属于 Limited availability；当核心浏览器具备互操作支持后进入 Newly available；再经过约 30 个月的支持周期，才可能进入 Widely available。

这个分层的价值在于把“每个浏览器、每个版本逐项查表”的起点变成一个更快的决策问题：如果只是内部工具，Newly available 可能已经值得评估；如果是面向广泛用户的支付、登录或内容阅读主路径，Widely available 仍然只是较稳妥的候选线，而不是免检通行证。

先用 Baseline 缩小候选范围，再看真实用户

实际采用时可以按下面的顺序问三件事：第一，特性处于哪个 Baseline 状态；第二，站点的 RUM 或访问日志中是否仍有较老浏览器、内嵌 WebView 或特殊设备；第三，特性失败时是局部样式退化，还是会阻断登录、下单、编辑等关键动作。

尤其要注意，Baseline 描述的是平台特性层面的共同支持，不会替你回答某个框架插件是否处理完整、某个 WebView 是否同步、辅助技术是否满足体验要求，也不会证明所有参数和边缘行为都一致。关键页面仍应回到 MDN 兼容数据或目标浏览器测试。

把 Baseline 结论落到工程配置

如果团队希望把“Widely available”作为默认候选，可以使用基于 Baseline 的 Browserslist 配置，再把站点自己的数据写进决策记录。配置本身不是兼容测试，它只是让编译、Lint 或目标浏览器列表有一个可追踪的起点：

{
  "browserslist": [
    "extends browserslist-config-baseline"
  ]
}

上面的 JSON 保持有效格式，因此不在代码块中插入注释。若特性只用于非关键装饰，可用能力检测配合渐进增强；若特性决定核心流程，则应准备旧路径，并把失败事件纳入上线监控：

if ("structuredClone" in globalThis) {
  // 现代浏览器走原生能力，减少自定义复制逻辑。
  state = structuredClone(source);
} else {
  // 旧环境保留可接受的降级路径，避免关键流程直接中断。
  state = cloneForLegacyBrowser(source);
}

示例中的检测只说明“能力是否存在”，并不等于你的数据结构、异常处理和性能都已验证。上线前仍要用目标浏览器执行关键路径测试；上线后观察错误率和降级命中，确认是否可以逐步退出 polyfill 或旧代码。

常见问题

Baseline Widely available 是否等于所有浏览器都支持？

不等于。它是核心浏览器集合和时间条件下的摘要，站点仍需考虑用户画像、WebView、特殊设备以及特性本身的细节。

Newly available 能不能用于生产环境？

可以评估，但要看失败成本。内部工具或可渐进增强的非关键功能通常更容易采用；支付、登录等主路径应先准备降级并验证用户环境。

为什么还要查 MDN 或 Can I Use？

Baseline 帮你快速判断方向，细粒度兼容表才能补充版本、参数、部分实现和具体平台差异。两者是互补关系。

把“兼容”写成可复查的工程决策

一个可维护的记录至少包含特性名称、Baseline 状态、目标用户环境、关键路径风险、检测或降级方案和复查日期。这样，团队以后面对新浏览器版本或用户分布变化时，只需更新证据和门槛，不必重新争论“听说现在能用了”。

可继续参考：https://web.dev/baseline、https://github.com/web-platform-dx/web-features/blob/main/docs/baseline.md。