配了三年前端，今天才发现兼容性状态一直在变——Chrome 把这件事用邮件订阅彻底原生化了

配了三年前端，今天才发现兼容性状态一直在变——Chrome 把这件事用邮件订阅彻底原生化了

前端有个很典型的工作流：评估一个新特性能不能用，上 caniuse 查一下，一看覆盖率 92%，心里有数了——然后就忘了这事。六个月后浏览器版本更新，覆盖率变了，或者某个关键浏览器突然支持了，团队不知道，还按老的判断来开发，结果就是线上 bug，或者特性早就该用但一直没上。

这个「查一次就忘」的工作方式，有个根本问题：兼容性不是静态的，是一直在变的，但你没有机制去追踪它的变化。

Chrome 团队在 web.dev 上线的 Baseline Alerts，把这件事彻底变成了主动推送。原理很简单：在 webstatus.dev 上订阅你关心的 feature/category/saved search，兼容性状态一变，就通知你——不需要再去手动查，平台直接告诉你。

支持的订阅维度很灵活。可以按单个 feature 订阅（比如只盯 View Transitions 或 Anchor Positioning），可以按整个分类订阅（CSS / HTML / JavaScript），也可以自定义 saved search——只看你实际在用的那些特性。触发条件有四种：feature 变为 newly available、变为 widely available（Baseline Widely Available）、获得另一个浏览器支持、以及最容易被忽视的——regression，某个浏览器降低支持。

通知方式直接接进工程工作流。Email 最简单，RSS 适合接入内部知识库，Webhook 可以直接推 Slack 或飞书——这才是真正有工程价值的地方：兼容性变更直接进团队的消息流，而不是躺在某个工程师的浏览器收藏夹里。

这套机制对工程团队的直接影响是：兼容性追踪从「人肉被动」变成「平台主动」。以前是等用户报 bug 才知道某个浏览器版本不支持了，现在是浏览器支持状态一变你就知道，甚至在功能上线前就知道。

三步下一步：

1. 去 webstatus.dev 创建一个账号；
2. 对你项目里已经用到的 CSS/JS 特性建一个 saved search，开启 email webhook 通知；
3. 把 Slack/飞书 webhook 配好，让兼容性状态变化直接进团队的工作流。