1、谁该为兼容性「背锅」？
领导："小明同学，用户反映你做的页面打不开。"
小明："怎么可能，我测过多次了。"
领导发来一段视频。小明找到对应的用户日志，上面赫然写着"foo.bar.at is not a function"。
小明瞬间想起，自己为了简化数组取最后一个元素的逻辑，用了ES2022的新特性Array.prototype.at()。最终，他不得不把代码改成let arr = foo.bar; arr[arr.length - 1]。
这样的场景，是不是似曾相识？
为了兼容箭头函数，我们被迫写了大量that = this；为了适配async/await，我们只好层层回调嵌套；为了处理scroll-end事件的兼容差异，我们无奈手写防抖监听scroll。这些与业务逻辑无关的「脏活累活」，像一块块甩不掉的石头，压得开发者喘不过气。
但有没有一种方式，能让普通开发者彻底摆脱兼容性的困扰？答案是：将浏览器兼容性处理从业务层剥离，交给架构层集中解决。当关注点分离后，业务开发者只需专注功能实现，架构层通过工程化工具链统一兜底——这才是现代前端最优雅的兼容性解决方案。
2、如何在架构层解决兼容问题
通过构建工具、组件库、样式体系等基础设施，一次性解决所有兼容性问题，让业务代码保持「纯净」。
2.1 转译抹平语法差异
Babel 是主流的语法转译工具，它允许我们自由使用ES6+的箭头函数、类、模块化等现代语法，同时在构建时自动将新语法转译为旧浏览器能识别的ES5代码。这种转换带来的不仅是效率提升，代码风格也会因统一的新语法而更简洁。SWC 及 TypeScript 同样具备强大的转译能力，成为现代前端工程的常客。
2.2 自动注入新API垫片
Babel 能处理语法，但无法处理新API——比如Promise、fetch或Array.includes。这时，Polyfill的价值就突显了，Polyfill 作为“功能垫片”，动态模拟浏览器缺失的能力。架构层可以通过babel的useBuiltIns配置、@rollup/plugin-inject、rollup-plugin-polyfill-inject等工具，在构建时自动检测目标浏览器缺失的API，并精准注入垫片代码。
2.3 封装DOM操作
现代前端框架（如React、Vue）的本质，是用声明式语法屏蔽底层的DOM操作。正因如此，如果这些个框架已经处理好了DOM操作的兼容性，业务层就能更加安心的开发业务了。以滚动事件为例：当业务层直接使用 @scroll-end 或 onScrollEnd 时，假如框架运行时已经自动处理了底层差异，开发者就能彻底告别手写防抖的繁琐。Vue、React 等组件化框架，可以也应该成为DOM兼容性问题的屏障。
2.4 图片格式自动转换
现代前端开发中涌现了许多新兴图片格式（如WebP、AVIF、SVG）。传统做法是手动准备多套图片，通过picture标签或CSS HACK适配，但这会增加业务开发的工作量。这种机械工作完全可以交给构建过程。我们在编写构建过程时可以对新格式图片进行自动转格式，业务层就能无视格式是否支持。我们看看示例代码
.example {
background-image: url("./foo.svg");
}
然后看看构建后效果
.example {
background-image: url("./foo-a6cb217a.png");
}
@media (color) {
.example {
background-image: url("./foo-31bdfe8c.svg");
}
}
非常的优雅。
2.5 建立样式体系
要写好样式绝非易事，样式往往需要密切配合业务场景。使用构建手段很难完美降级，因此建立完善的样式体系是更优解：
- 组件库层：业务人员使用架构组提供的公用组件，从源头避开样式编写
- 公共样式库：若组件功能无法满足需求，可使用预定义的公共样式类
- Mixin 库：业务人员编写自定义样式时，通过 Mixin 复用兼容代码片段
- PostCSS 后处理：作为样式界的 Babel，自动处理浏览器前缀、单位转换等兼容问题
这种分层体系让样式兼容性问题在架构层集中解决，业务层只需关注样式逻辑而非兼容细节。
2.6 模块化相关兼容性处理
有些新语法特性（如top-level-await）无法在Babel层完全处理。这时需要打包工具（如Rollup）在专门处理模块间的关系。我们除了在编写构建方案时，要在renderChunk阶段把top-level-await转为Promise，还要让模块运行时支持异步模块。这种架构级处理，使高级语法安全落地。
2.7 使用分条件加载让新浏览器轻装上阵
经过构建工具处理后，产物代码中会包含大量「补丁」。这些补丁在新浏览器中完全不起作用，反而会增加加载时间。架构层可以通过「分条件加载」优化体验：根据浏览器对新特性的支持情况，动态加载不同版本的代码。
<script type="module" src="modern.js"></script>
<script nomodule src="legacy.js"></script>
上面代码以是否支持原生esm为界，加载2个版本。2个版本是由构建工具自动生成的，我们只需要写一份代码。
通过原生 ESM 支持度划分版本只是起点，想要更精细可以构建更多个版本。目前我已经实现了构建出4个版本了。
3、使用代码规范约束不兼容代码
对于无法兼容的特性，架构层还可以通过typescript、eslint、stylint来约束业务代码。
以top-level-await为例，很多人并没有配置好top-level-await的降级，万一哪天有个小伙网上找了个例子就用了，就会导致兼容问题。为防这种情况，我们可以在eslint或typescript上先做好限制，禁止使用top-level-await。 等哪天架构层做好降级方案后，再移除相应限制。这种 "先堵后疏" 的策略，能有效避免兼容性事故。
4、业务层该做什么？
虽然兼容性处理以架构层为主，但业务层并非完全「躺平」。业务开发者的唯一职责，是配置browserslist。架构层会根据这个配置自动调整转译规则、垫片注入和代码优化策略，实现 "一处配置，全链路适配"。
{
"browserslist": "<= 100%" // 一行代码解决一切兼容问题，真TM爽
}
5、总结
「不处理浏览器兼容性」不是逃避问题，而是通过架构设计将复杂度隐藏在幕后。我们相信：专业的架构层能比个体开发者更高效地解决共性问题。
当业务开发者不再被兼容性束缚，前端团队才能真正释放生产力，用代码创造更大的业务价值。毕竟，最好的兼容性处理方式，是让开发者忘记「兼容性」的存在。
