Can I use 使用指南：浏览器兼容表的读法、数据来源与边界

Can I use（caniuse.com）是一个公开的浏览器支持查询站。输入 CSS 属性、HTML 元素或 JS API 名称，就能看到各浏览器从哪个版本开始支持。它解决的是“这段代码放进目标浏览器能不能跑”这个具体问题，给出带版本粒度的支持表，而不是笼统的兼容性印象。

它解决的是哪一类问题

前端选型卡住时，问题往往很具体：某个 CSS 属性能不能直接用，某个 API 在旧版 Safari 上是不是空白。这类判断靠翻博客容易过时，靠记忆更容易出错，需要一份按版本排列的事实表。

它不提供 polyfill，也不生成兼容代码。你拿到的只是事实层的信息：支持、不支持、部分支持、未知。要不要用、怎么降级，仍然由项目自己决定。

举个具体例子。新项目想用 CSS 子网格，打开 CSS Grid 特性页 就能看到各引擎从哪个版本开始实现。看完再决定要不要为旧版本保留单层网格的回退写法，整个过程两分钟左右。

对写文档的人同样有用。文中要写“某特性自 Chrome 111 起支持”这类句子时，引用表格比凭记忆写可靠得多。查 Passkey 这类较新的 API 也是同样的顺序：先看版本分布，再决定实现细节写多深。站内那篇 Passkey 通行密钥流程说明就是按这个思路组织的。

一张表能读出多少信息

打开任意特性页，横向是浏览器家族，纵向是版本号，单元格用颜色表示状态。图例只有四档，几乎没有学习成本。

“部分支持”这一档容易被误读。它通常意味着主要用法已经可用，但某个子属性缺失，或者需要加前缀、需要特定参数。表格下方的备注会写明差异。读表时应当连带看备注，只看颜色会漏掉关键限制。

2025 年 10 月 11 日的站点更新后，搜索结果可以切换成列表视图。列表里会带上 Baseline 状态和全局使用率区间，适合一次扫一批特性做取舍，不必逐个点开。

读表时还要注意行是怎么划分的。iOS 上所有浏览器都跑在 WebKit 上，所以 Safari on iOS 一列基本能代表 iPhone 的整体情况。安卓侧则要分开看 Chrome、三星浏览器与各家 WebView，它们的更新节奏并不同步。

数据从哪里来，多久更新一次

支持数据放在 GitHub 的 Fyrd/caniuse 仓库，任何人都可以提交修正或新增特性。仓库里的 fulldata-json/data-2.0.json 是全量数据。文件按 CC BY 4.0 授权，引用时注明来源为 caniuse.com 即可。

• 主数据：由维护者与社区在仓库中维护，站点通常在几天内处理新信息。
• 部分条目：来自 MDN 的 browser-compat-data，这部分数据每周同步一次。
• 使用率：来自 StatCounter GlobalStats，页脚标注为 2026 年 9 月的统计。
• 2025 年 10 月 11 日起：搜索与列表并入 web-features 项目的数据和 Baseline 状态。

更新节奏有两处旁证。站点的更新日志里，2026 年 1 月 10 日加入 CSS Grid Lanes。2026 年 3 月 5 日又加入 video 与 audio 的 loading 属性。npm 上的 caniuse-lite 在 2026 年 10 月 29 日发布 1.0.30001820 版本，与仓库的数据提交日期一致。

使用率要留意统计口径。浏览器使用率表页面写明桌面数据来自 StatCounter，移动版本是按其他来源推算的。页面底部还给出“Total amount accounted for: 97.49%”，也就是仍有约 2.5% 的流量没有被覆盖。

除了查表，还有哪些入口

索引页的规模可以量化：CSS 组编号排到 474 项，JS API 组排到 366 项，两个分组各自还带一个“全部”汇总项；SVG 与 JS 组分别是 10 项和 41 项。这个体量足够覆盖日常选型遇到的大部分问题。

如果要把判断写进构建流程，用 caniuse-lite 更合适。它是 caniuse-db 的精简版本，只保留必要字段，安装体积比全量数据小很多。Browserslist 的 README 说明其查询会读取 caniuse-lite 的数据。因此“fully supports css-grid”这类写法能直接筛出版本，Autoprefixer、Babel 等工具也走同一条链路。

这些入口的说明集中写在 About 页面 的问答里，包括能不能引用数据、如何提交新特性、多久更新一次。页面还提供了订阅源，跟进新增特性时不必每天手动翻首页。

这类查询型站点适合固定在书签栏，和 regex101 的正则调试 类似：都属于查一次就能拿到确定答案的工具，不必装客户端。站点设置里还能切换到色盲友好配色，选项会被记住，长期看表时更省眼。

边界、适用人群与上手顺序

五个需要留心的边界

1. 支持不等于没有 bug。官方对“已支持”的定义是主要用途基本满足，并不保证每个子特性、每种边缘写法都一致。
2. 使用率存在样本偏差。StatCounter 统计的是可采集站点，和你的实际访客结构未必吻合，移动端份额还是推算值。
3. 移动浏览器只记录当前版本。Browserslist 文档提到 Can I use 对部分移动浏览器仅有当前版本数据，查历史版本会失真。
4. 有些场景不在覆盖范围。HTML 邮件要另看 caniemail.com，性能、可访问性、隐私行为也不在这张表里。
5. 对比工具当时并未并入 web-features。2025 年 10 月的更新说明明确写了这一点，用对比功能时要清楚它只覆盖原有特性。

兼容性也只是上线前检查的一环。协议行为、缓存策略这些服务端侧的问题需要另外确认，可以配合 HTTP 强缓存与协商缓存的配置思路 一起看，避免把两类问题混在一起判断。

适合谁用

前端开发、独立开发者、技术写作者，以及需要评估兼容性的测试与产品岗位。做技术选型评审时，把表格截图、目标版本区间和查询日期一起放进文档，比口头结论更有说服力。团队协作的话，可以把常用特性的查询结果整理成内部备忘，新人上手时不用重复查一遍。

上手顺序

1. 先确定项目要支持的浏览器范围，再对照使用率表核对这份范围是否合理。
2. 搜索特性名，用列表视图看 Baseline 状态与全局使用率区间，快速筛掉风险项。
3. 打开特性页逐版本确认，重点读“部分支持”对应的备注。
4. 把结论写进项目文档，注明查询日期，方便半年后复核。
5. 需要自动化时，改用 caniuse-lite 配合 Browserslist 查询，把版本判断交给构建流程。

常见问题

Can I use 是免费的吗

查询功能免费，页面带广告。Patreon 每月 1 美元可以关闭广告，不影响数据本身。

表格数据能直接引用到文章里吗

可以。仓库数据按 CC BY 4.0 授权，注明来源为 caniuse.com 即可，商业文档同样适用。

为什么查不到某个移动浏览器的旧版本

移动端通常只维护当前版本，桌面端才保留完整历史。查旧版本时以桌面数据作参考，并在结论里留出误差区间。

它和 MDN 的兼容性表有什么区别

两者数据互通，MDN 的 browser-compat-data 就是上游之一。MDN 更贴近文档阅读，Can I use 更偏横向对比与使用率，选哪个取决于你要读用法还是要做取舍。