别再追着 Can I Use 刷新了，Baseline Alerts 已经能帮你盯浏览器兼容性了

导语

前端工程师选 API 时，最怕的不是“文档看不懂”，而是“官方说可用，但用户浏览器版本还不够”。以前大家靠 Can I Use、caniuse.com、MDN 兼容表手动刷新，但浏览器特性一多，这些表根本盯不过来。现在 Web Platform Status 上线了 Baseline Alerts，开始把兼容性从“查表”变成“订阅更新”，把判断条件从“我猜能用了吗”变成“官方告诉我终于能用了”。

正文

问题：兼容性判断这件事，为什么一直做不好？

很多前端选型决策其实是被浏览器兼容性推着走的：

• container-type 在 2023 年已经进 Baseline 了，但你在代码里加注释“Chrome 111+”，还是要问一句“要不要加 fallback”。
• scroll-timeline 和 view-transitions 明明已经进了 Baseline，但团队里还有人截图了 Can I Use 的绿色块，质疑“真能用了吗”。
• has() 选择器进 Baseline 前后，很多项目因为历史包袱不敢立刻切。

根因不是信息不够，而是信息太分散。 MDN、Can I Use、Chrome Status、Bugs Database 各自维护一套状态，前端工程师只能反复刷新、交叉比对，漏了就等于踩坑。实际上，前端真正需要的不是“兼容性表”，而是“特性状态变更的通知”。

方案：Baseline Alerts 把兼容性变成订阅制

Baseline 是 Google 主导的浏览器特性兼容性统一标签体系，核心结论是三档：

• Baseline Widely available：所有主流浏览器当前版本都支持。
• Baseline Newly available：最新版浏览器刚支持，还没完全普及。
• Limited availability：部分浏览器支持，需要 fallback。

以前你得手动去 webstatus.dev 查，现在 Baseline Alerts 把这个状态变更变成了可订阅事件。具体功能包括：

• 特性进入 Baseline Widely available 时，自动发邮件或 RSS 通知。
• 可以订阅单个特性，也可以按特性类型订阅（比如所有 HTML、所有 CSS）。
• 支持 Slack webhook，直接把通知推送到团队频道。

这意味着，你可以把 container-queries、view-transitions、field-sizing 这些“等进 Baseline 就切”的特性加入订阅，特性一旦跨线，系统就发通知。不用再每周刷一次 caniuse.com。

代码/操作：怎么用 Baseline Alerts？

第一步：订阅特性状态

1. 打开 webstatus.dev，用 GitHub 账号登录。

2. 进入某个特性的页面，比如 JPEG XL 或 CSS container queries。

3. 点击 Subscriptions，选择通知方式：邮件、RSS 或 Slack webhook。

4. 设置触发频率：每次变更、每周汇总或每月汇总。

第二步：保存搜索并订阅一组特性

如果你关心的是整组特性，可以用搜索语法保存：

• 所有 HTML 特性：group:html
• 所有 CSS 特性：group:css
• 单个特性：直接搜特性名，比如 view-transitions

保存搜索后，订阅这个搜索，就能收到整组特性的状态变更通知。

第三步：结合 Browserslist 做项目准入

Baseline 现在已经可以和 Browserslist 配合：

{
  "browserslist": [
    "last 2 Chrome versions",
    "last 2 Firefox versions",
    "last 2 Safari versions",
    "not dead"
  ]
}

配合 Baseline Alerts，你可以设定规则：特性进 Baseline Widely available 之后，项目才允许采用。这样团队就不需要争论“这个特性到底能不能用了”。

结论：兼容性判断这件事，值得从“手动查”切到“被动订阅”

前端不是缺信息，缺的是信息触达的确定性。Baseline Alerts 的价值，是把“我去看”变成“它来告诉我”，把模糊的“应该能用了吧”变成明确的“已经 Widely available”。

如果你的团队还在每周手动刷新 Can I Use，或者项目 README 里写着“Chrome 111+ 可用”，现在就可以试一下 Baseline Alerts，把兼容性决策从“人盯”改成“订阅制”。

收尾

下一步建议：去 webstatus.dev 订阅你当前项目里最关心的 2-3 个特性，用一周时间观察通知质量。如果推送及时、噪音可控，再把基线规则写进团队的兼容性准入标准里。