浏览器兼容性手册

01特性兼容总表

下表汇总 31 个高频前端特性的最低支持版本，覆盖 Chrome、Edge、Firefox、Safari 与 iOS Safari 五端。单元格数字为该浏览器首个完整支持的版本；◐ 表示该版本起仅部分支持（脚注说明）；✗ 表示从未支持。

02兼容策略

渐进增强 vs 优雅降级

这是应对兼容差距的两种方向相反的工程哲学。

实际项目中两者常组合使用：内容与核心链路渐进增强（弱网、旧设备也能完成主任务），辅助能力优雅降级（如不支持 container queries 时退回媒体查询布局）。

特性检测：@supports

与其猜测浏览器版本，不如直接问浏览器「你支持吗」。CSS 的 @supports 与 JS 的 CSS.supports() 是标准答案，比 UserAgent 嗅探可靠得多。

最小代码示例：CSS 与 JS 两种特性检测

/* CSS：仅当浏览器支持容器查询时才启用增强布局 */
@supports (container-type: inline-size) {
  .card { container-type: inline-size; }
  @container (min-width: 480px) {
    .card__body { display: grid; grid-template-columns: 1fr 2fr; }
  }
}
/* 不支持时整体降级为媒体查询方案 */
@media (min-width: 768px) {
  .card__body { display: grid; grid-template-columns: 1fr 2fr; }
}

// JS：运行时探测后再加载 polyfill 或走降级分支
if ('IntersectionObserver' in window) {
  const io = new IntersectionObserver(lazyLoad);
  io.observe(imgEl);
} else {
  // 不支持时直接用 loading="lazy" 或滚动事件兜底
  imgEl.loading = 'lazy';
}
if (window.structuredClone) { clone = structuredClone(obj) }
else { clone = JSON.parse(JSON.stringify(obj)) }

Polyfill 与 Babel 编译目标

特性检测决定「要不要补」，Polyfill 负责「补什么」，Babel 负责「把语法编译成目标浏览器能解析的形式」。两者分工：语法转译（箭头函数、可选链等）靠 Babel/SWC 编译，运行时 API 缺失（Promise、Array.prototype.at 等）靠 Polyfill 注入（见 Babel 与 Polyfill 词条）。

最小代码示例：browserslist 与 Babel targets

// .browserslistrc（被 Babel、Autoprefixer、ESLint 共用）
> 0.5%
last 2 versions
not dead
not ie 11      // 明确放弃 IE

// babel.config.js
module.exports = {
  presets: [[
    '@babel/preset-env', {
      targets: { chrome: '90', firefox: '88', safari: '14', ios: '13' },
      useBuiltIns: 'usage',   // 按代码实际用到的 API 注入 core-js
      corejs: 3
    }
  ]]
};

Autoprefixer 与 CSS 兼容

CSS 的兼容成本主要在厂商前缀与属性命名差异。Autoprefixer 基于 browserslist 自动补齐 -webkit- / -moz- 等前缀，PostCSS 生态还能配合 PostCSS 插件把现代 CSS（如嵌套）降级编译，让书写体验与兼容性解耦（见 CSS 嵌套语法）。

/* 源码（只写标准语法） */
.sticky { position: sticky; top: 0; }

/* Autoprefixer 按 browserslist 自动输出： */
.sticky {
  position: -webkit-sticky;  /* Safari 6.1~13 需要 */
  position: sticky;
  top: 0;
}

浏览器市场份额说明

兼容目标不是「支持所有浏览器」，而是「覆盖目标用户的主流环境」。决策建议：

• 以 真实用户占比定底线：统计站点近 3 个月数据（Google Analytics / 百度统计），通常将累计 99% 用户作为支持范围，剩余 1% 给出可用的降级体验而非完整支持
• Chrome 系份额最高（含 Edge、国内浏览器、安卓 WebView），但国内环境还需注意安卓 WebView 版本常落后于 Chrome 正式版 1~2 个大版本
• iOS Safari 版本与系统绑定且更新慢：老款 iPhone 停在 iOS 15/16 很常见，因此 iOS 15~16 常是移动端底线（对应 :has()、container queries 的取舍点）
• Safari 桌面版份额小但不可忽视（设计、教育、外企场景占比高），其特性支持常滞后 Chrome 1 年以上
• 内部系统先问清用户画像：企业内网可能锁死 Edge 旧版甚至 IE 11，此时策略完全不同

03经典兼容问题与方案

这些是兼容史上反复出现的问题。现代环境下多数已无需处理，但面试与存量项目维护中仍是高频考点。

04使用建议

• 先查后写：使用新特性前查一下本表或 词条大全 对应词条（如 :has()、容器查询），确认目标用户底线能覆盖
• 优先渐进增强：内容型站点保证无 JS / 无现代 CSS 时的核心可用性；重度应用再谈优雅降级
• 检测优于嗅探：用 @supports / in 操作符探测能力，而不是判断 UA 字符串（国产浏览器 UA 常伪装）
• 编译层兜底：Babel targets + core-js + Autoprefixer 统一由 browserslist 驱动，把兼容决策收敛到一处配置
• 持续校准：每季度复核一次目标浏览器份额与 caniuse 数据，及时收窄 polyfill 范围（详见 Core Web Vitals 对包体积的要求）