降级策略原则：渐进增强 vs 优雅降级，如何选择？
做前端久了，你会发现一个铁律：用户的环境永远比你想象的更分裂。有的用户还在用 IE11，有的已经用上了最新的 Chrome 120。同一个 API，老浏览器不支持，新浏览器功能更强。这时候，你面临一个根本选择：以谁为基准，往哪边扩展？ 这就是「渐进增强」和「优雅降级」的核心区别。
两种策略，两种思维
| 维度 | 渐进增强 (Progressive Enhancement) | 优雅降级 (Graceful Degradation) |
|---|---|---|
| 出发点 | 从最基础的功能开始，逐步叠加增强 | 从最完整的功能开始，为低版本提供降级 |
| 开发顺序 | 先保证所有浏览器能用，再给高级浏览器加特效 | 先开发高级浏览器版本，再处理低版本兼容 |
| 用户体验 | 低版本用户功能完整但体验平淡，高版本用户享受增强 | 高版本体验最爽，低版本用户可能缺失某些功能 |
| 典型场景 | 政府网站、金融系统、企业后台（需覆盖老旧环境） | 游戏、可视化应用、营销页面（优先保证现代体验） |
| 心智模型 | 「先能用，再好用」 | 「先做好，再凑合」 |
我的理解：渐进增强更像「自底向上」搭积木，基础层是 HTML 语义化，中间层是 CSS 兜底，顶层是 JS 增强。优雅降级更像是「自顶向下」做减法，先做完整版，然后用 polyfill 或特性检测把不支持的降级掉。
哪个更靠谱？看三件事
说实话，我早年也纠结过。后来踩了坑才明白，选哪个取决于三个因素。
- 用户环境分布：如果用户群体里有大量 Edge Legacy、UC 浏览器、三星浏览器等小众环境，渐进增强更安全。我曾在某政务项目中遇到 8% 的 IE11 用户，强行用优雅降级导致某些表单提交不了，被客户投诉。
- 功能的核心程度：如果是核心交互（登录、支付、数据提交），必须保证所有浏览器都能正常执行。这时候用渐进增强，先确保基础逻辑跑通，再考虑动画、过渡等锦上添花的东西。
- 团队迭代节奏：如果你的产品每周发版，且现代浏览器占 90% 以上，优雅降级能让你更快上线新特性。反之，如果是长期维护的项目，渐进增强的代码更稳定，未来迁移也轻松。
一个简单的判断方法：拿你现在正在支持的最低浏览器，如果它连fetch、Promise、Array.from都不支持，那就别想着优雅降级了，老老实实从基础 HTML 表单开始渐进增强。
我曾经踩过的一个坑
几年前我做了一个数据可视化大屏项目，用户全是内部高管，用的都是最新版 Chrome。我当时贪快，直接用了 ES6 模块、ResizeObserver、CSS Grid 等一堆高级特性。结果上线没两天，有高管用 iPad 打开，页面完全空白——因为那个 iPad 的 Safari 版本不支持 ResizeObserver。这就是典型的优雅降级失败案例：我根本没有为低版本浏览器准备任何降级。
后来我改成渐进增强：先用 window.resize 事件兜底布局，再检测 ResizeObserver 可用时替换。虽然代码多了几十行，但再也不怕「领导的 iPad」了。
实操：如何落地选择？
别光听理论，我给你一个具体的决策流程。这也是我目前在项目中实际用的。
- 列出目标浏览器列表（通过 Google Analytics / 友盟等获取真实数据）
- 确定关键功能的「红线」：哪些功能是必须100%可用的？哪些是「有更好，没有也能接受」？
- 做特性检测：对每个红线功能，在开发前就写一段检测代码跑在最低版本浏览器上，看它到底支不支持。
- 选策略：如果红线功能在低版本浏览器上完全无法 polyfill，直接走渐进增强；如果能用 polyfill 补上，走优雅降级。
// 伪代码：混合策略
if (supports('ResizeObserver')) {
// 现代方式：用 ResizeObserver
const ro = new ResizeObserver(entries => { ... });
ro.observe(element);
} else {
// 降级方案：用 window.resize + 定期轮询
window.addEventListener('resize', handleResize);
// 每 500ms 检查一次
const fallback = setInterval(handleResize, 500);
// 别忘了在销毁时清理
}两种策略不是非黑即白
你想想看，实际项目里很少有只用一种方案的。大多数情况是混合使用：页面整体采用渐进增强的思维，但在某些非关键交互（比如动画、过滤筛选）上使用优雅降级，用特性检测决定是否执行。
举个例子：你做一个商品列表页。
- 基础功能（加载数据、渲染列表、点击跳转）：用渐进增强，确保所有浏览器都能工作。
- 增强功能（懒加载图片、骨架屏、弹窗动画）：用优雅降级，检测到不支持
IntersectionObserver就退化成直接显示所有图片。
这样一来，低版本用户能正常浏览商品，高版本用户享受更流畅的体验。两拨人都不觉得难受。
注意：千万不要在同一个功能上同时使用两种策略。比如一个按钮点击事件，既写了 ES6 class 又写了 ES5 的 prototype，那就重复了。合理做法是用 Babel 编译后在运行时通过特性检测切换分支。
一张图理清选择逻辑
下面这张流程图是我常用的选择器。每次启动新模块时，我都会快速过一遍。
我的习惯：在项目初期，我会先用渐进增强把核心流程跑通，哪怕只有普通文本和按钮。然后在一周内，逐步对每个增强特性做降级处理。这样即使中途需求变了，也不会因为降级方案没做好而阻塞上线。
选错了怎么办？
万一你选择了优雅降级但后来发现低版本用户很多，或者选择了渐进增强但用户抱怨体验太普通——别慌，可以重构。关键在于你的代码是否做好了抽象。把功能逻辑和 UI 渲染分离，把特性检测封装成可切换的模块，就能在两种策略之间平稳迁移。
我在一个老项目里，最初完全用的优雅降级。后来用户中多了很多老手机，我就把核心交互重构为渐进增强——只花了两个迭代。前提是之前每个功能都通过FeatureDetect 对象做了一层封装，改起来很快。
// 好的抽象示例
const FeatureDetect = {
supportsResizeObserver: 'ResizeObserver' in window,
supportsIntersectionObserver: 'IntersectionObserver' in window,
supportsFetch: 'fetch' in window,
// ...
};
// 在代码中只依赖 FeatureDetect 判断
if (FeatureDetect.supportsResizeObserver) {
// 使用 ResizeObserver
} else {
// 降级为 resize 事件
}
说白了，没有正确的策略，只有适合当前项目用户真实情况的策略。记得每三个月检查一次浏览器分布数据，策略也要跟着更新。嗯，这就是我的经验之谈。