你以为 caniuse 全绿就能上线了？今天 Baseline 2026 把这件事从「能用吗」彻底变成了「该用吗」

你上线前查了 caniuse，全绿，信心满满。结果用户反馈：iOS 12 白屏、Android 4.4 错版、低端机直接崩溃。

这不是你的 bug，是 caniuse 告诉你的只是「对不对」，从来没告诉你「对谁对」。

Chrome for Developers 2026 年的一篇文章把这件事说清楚了：Legacy JavaScript audit 会检测到你项目里有多少 polyfill 和 transform 是为那些「Baseline 已经全绿的特性」加的——换句话说，你为那些浏览器自己就能做的事在多写代码，而且写进包里了。

这个问题，Baseline 2026 终于给了一个框架。

Baseline 是什么：不是「支不支持」，是「安不安全」

Baseline 是 WebDX Community Group 维护的跨浏览器兼容性标准，它的核心价值是把「这个特性可以用了吗」这个问题，从模糊的「看 caniuse 经验判断」，变成一个可量化的三档标准：

Limited availability — 还没跨过所有主流引擎，支持不完整，上生产需要 polyfill 或者渐进增强。

Newly available — 四大核心浏览器（Chrome、Edge、Firefox、Safari）刚好都支持了，这个特性第一次达到「全绿」状态，但你还需要看自己的用户设备分布来判断是否该用。

Widely available — 这个特性已经在所有主流浏览器稳定版里跑了 30 个月以上，版本覆盖率足够大，可以直接当成平台能力来用，不需要 polyfill，不需要 @supports 渐进增强。

Baseline 2026 官方清单（web.dev/baseline/2026）里，CSS 和 HTML 部分新增的实用特性包括：

field-sizing: content — textarea/input 根据内容自动调整高度，不用 JS 算 scrollHeight 了。

Container style queries — 组件可以根据父容器的 CSS 变量做样式决策，不用再靠媒体查询查视口宽度。

:open 伪类 — 替代 classList.toggle 管理弹窗/dialog/popover 的打开状态。

contrast-color()、shape()、text-indent: each-line/hanging — 具体的 UI 场景功能，原先需要 JS 或者复杂的 CSS 组合来实现。

JavaScript/Web API 侧新增 Math.sumPrecise()、Iterator.concat()、Map.getOrInsert()、Navigation API、Trusted Types、Zstandard 压缩、WebTransport 等，这些是偏底层能力，对应原先的 axios、lodash、部分日期库的场景。

为什么要用 Baseline 来审你的依赖

Smashing Magazine 2026 年 8 月的一篇实操文（Jad Joubran）用这个框架对项目做了一次依赖审计，结果很直接：一个典型中型前端应用，大约有 60~90KB 的 minified + gzipped JavaScript 是多余的——浏览器原生就能做这些事。

他们把可替代的库分成几个集群来审：

国际化集群 — Intl.DateTimeFormat / Intl.NumberFormat / Intl.RelativeTimeFormat 替代 timeago.js（~1KB）、numeral（~3.9KB）、humanize-duration（~6.6KB）。这些库在 Baseline 体系里长期是 Widely available 的，根本不需要 polyfill，直接删。

HTTP 客户端集群 — fetch + AbortSignal.timeout() 替代 axios（~17KB）。当然，axios 的拦截器、重试机制是 fetch 还不覆盖的部分，这个要逐项判断，不能无脑替。

UI 原语集群 — <dialog> 元素 + Popover API 替代 tippy.js、focus-trap 之类的弹窗 tooltip 库（~24KB）。这个集群在 Baseline 2025 已经大量进入 Widely available，Popover API 在 2025 年 1 月正式加入。

Lodash 工具集群 — structuredClone 替代 lodash.cloneDeep、Object.groupBy() 替代 lodash 的分组函数，整体 ~8KB 级别。

Temporal 的例外 — Temporal.now() 作为 Date 的原生替代品，polyfill 体积 44KB，比它要替代的 dayjs（3KB）还大，这个不能替。这是少数「原生方案反而更重」的案例，需要等 Safari 稳定版发布后整个 polyfill 生态缩小再判断。

整个审计流程 Jad Joubran 总结了五步：npm ls 拉依赖列表 → Bundlephobia 查每个包的体积 → webstatus.dev 查 Baseline 状态 → 问自己三个问题（用户设备支持吗、polyfill 成本多少、平台能力覆盖真实使用场景吗）→ 渐进增强替换。

为什么 caniuse 全绿不等于「该上线了」

你可能见过这种情况：某个 CSS 特性在 Chrome 126、Firefox 126、Safari 18 上全绿，但你的业务数据告诉你 15% 的用户还在 iOS 15——Safari 15 不支持这个特性，但 caniuse 不会告诉你这个，因为 caniuse 统计的是「最新版本」，不是「你的用户手里那台设备」。

Baseline 的价值就在这里：它不只是告诉你「支不支持」，它还通过 Widely available 这个 30 个月跨度的档位，帮你判断「这个特性的版本覆盖率够不够让你放心上线」。

St Albans Web Design 的一篇文章给了一个具体的判断原则：Widely available 的特性，直接当平台能力用，不需要 @supports，不需要 polyfill。Newly available 的特性，先确认你的用户设备分布，再决定是直接用还是渐进增强。

一个具体的检查方式：Chrome DevTools 里有 Legacy JavaScript audit，直接跑一下，它会标出你包里有哪些 polyfill 是为那些 Baseline 已经全绿的特性加的。超过 5 KiB 的 polyfill 体积就会触发审计失败。

下一步：建一个季度节奏

思路很简单：每季度拿出半小时，跑一次依赖审计。

步骤：

1. 拉依赖列表：npm ls --depth=0，把直接依赖全列出来。

2. 查 Baseline 状态：打开 webstatus.dev，搜索每个库对应的原生替代方案。如果替代方案是 Widely available，直接标记为「可删」。

3. 量 polyfill 成本：用 Bundlephobia 查目标 polyfill 的体积。如果原生 polyfill 比库还重，这项跳过（比如上面说的 Temporal）。

4. 渐进增强替换：对于 Newly available 的特性，用 if (featureName in window) 做特性检测，保持降级方案。上线后 GA 监控错误率。

5. Browserslist 同步：确保你的 browserslist 配置里加 baseline widely available，让构建工具不再为那些已经是平台能力的特性生成 transform 代码。

Baseline 2026 的核心变化不是它加了多少新 API，而是它给了一个团队可以共享的判断语言。 以前「这个能不能上线」是经验判断，现在可以直接说「这个 Widely available，直接替」，或者「Newly available，先查用户设备分布」。

你的下一个技术债清单，可能比你想象的要短得多。