企业官网建设流程全解析

那次线上事故我记得很清楚：一个内容页在某款常见旧内核浏览器上直接白屏，排查到最后，问题定位在一个很不起眼的API调用上——新写的懒加载逻辑用了一个旧环境根本不存在的接口，脚本在初始化阶段就抛错，整个页面跟着遭殃。

当时同事的第一反应是“加个判断不就行了”，但真正扎心的问题在后面：这个功能在能力不足的环境里到底应该长什么样，是整个团队从未定义过的事。也就是从那次开始，我把“优雅降级”和“渐进增强”这对老概念重新翻出来，认真捋了一遍它们的“道”与“术”。

这篇内容想聊清楚的就是这件事：两种前端兼容策略的出发点有什么本质区别，落到代码和工程流程里分别该怎么操作，以及现实项目里到底怎么选。适合刚接触兼容策略的前端开发者，也适合正在为老设备兼容问题头疼的技术负责人。

1. 浏览器兼容的岔路口：先想清楚“谁是你的基准环境”

1.1 两个策略的一句话定义

优雅降级（Graceful Degradation）的思路是：先给能力最强的环境做最完整、最丰富的实现，然后针对能力较弱的环境，把某些功能删掉或换成低级版本，保证页面“虽然差一点，但还能用”。

渐进增强（Progressive Enhancement）恰好反过来：先从能力最弱的环境出发，用最基础的 HTML 和 CSS 把核心内容和操作做出来，保证它在任何环境里都能读、能用；当检测到浏览器支持更强的能力时，再往上叠加 JavaScript 交互、高级样式、新 API 带来的体验增强。

一句话总结：优雅降级是“先做满，再往回删”；渐进增强是“先做地基，再往上盖”。

1.2 方向上的本质差异

这两个策略虽然目标都是“让更多环境能用”，但思维模型完全相反，直接影响代码怎么写、功能怎么组织。

用做饭类比：优雅降级像是先按十道菜的标准备好一整桌，发现客人胃口小，再撤掉几道；渐进增强则是先保证一碗米饭管饱，确认客人能吃辣，再逐步加菜。前者照顾的是“最丰盛的样子”，后者照顾的是“无论如何都要吃上饭”。

这个差异会传导到每一个具体决策上：

知道了方向差异，再往下看这两种策略各自的门道和实操，很多“为什么代码写成这样”的困惑就能解开。

2. 优雅降级的道：把“删减能力”认真当成一项设计任务

2.1 完全体优先的开发心智

选择优雅降级，意味着团队默认现代环境是“标准形态”，所有功能先按最完整的状态开发：交互要顺滑、动效要丰富、布局要精良、新 API 能上就上。这种心智的好处很直接——开发时不需要自我设限，产品体验的天花板拉得比较高。

但问题也藏在这里。降级这件事在多数团队里根本不是“设计任务”，而是“事后补救”。新功能上线前，大家都盯着完美形态做验收；至于旧环境怎么办，往往等用户报障了才想起来补一个判断。

我在实际项目里见过太多这种写法：功能主体写得漂漂亮亮，降级路径是最后十分钟加的一段 if 分支，只覆盖了“初始化时能不能用”这一层，根本没有想过“运行过程中出问题怎么办”“降级之后要不要提示用户”。

2.2 降级不是 bug，是产品决策

真正的优雅降级，要求把“环境不支持时怎么办”当成和“功能怎么做”同等重要的产品决策。

举个例子：某个页面用 Canvas 做数据可视化大屏，在旧环境里 Canvas 可能还在，只是性能很差。降级方案不是直接弹一行“请升级浏览器”就完事——你要决定是切换到表格展示数据，还是渲染一张静态图片，还是真的什么都不要。每一层都有不同的实现成本、不同的信息完整度，这个选择应该由产品和开发一起拍板，而不是让用户面对一个莫名其妙的空白区域。

所以优雅降级的“道”很简单：先承认“删减”也是功能设计的一部分，然后认认真真回答三个问题——什么能力必须保留、什么能力可以降成什么形态、什么能力干脆不要。回答清楚了，后面的“术”才有地方落。

3. 优雅降级的术：三个我踩过的翻车现场与补救方案

说完道，看术。这一节我直接复盘三个真实踩过的坑，每一个都是降级代码本身成了新的缺陷源。

3.1 翻车现场一：懒加载检测被绕开，整个页面白屏

第一次踩坑就是文章开头那个事故。当时的代码结构大致是这样：

// 初始化阶段很认真地做了检测 if ('IntersectionObserver' in window) { initLazyload(); } // 但 initLazyload 内部，以及后续的回调里，大量直接用了 IntersectionObserver function initLazyload() { const observer = new IntersectionObserver(/* ... */); observer.observe(/* ... */); }

检测确实写了，但只检测了“初始化”这一个入口。代码里其它地方还有对 IntersectionObserver 的引用，旧环境脚本解析到那里直接抛错，页面白屏。

补救方案是把检测下沉到真正使用它的地方，并提供一个完整的降级实现：

function setupLazyload() { if ('IntersectionObserver' in window) { const observer = new IntersectionObserver(onIntersect, { rootMargin: '200px' }); images.forEach(img => observer.observe(img)); } else { // 降级实现：滚动监听，只保留“接近视口就加载”的核心逻辑 // 注意：这里的代码只能用最基础、最普遍支持的 DOM API window.addEventListener('scroll', throttle(onScrollCheck, 150), { passive: true }); onScrollCheck(); } }

关键教训：降级分支里使用的语法和 API，必须比主分支更保守，绝对不能在降级路径里继续依赖那些“在新环境里理所当然存在”的东西。

3.2 翻车现场二：CSS 降级被层叠顺序反杀

第二个坑在 CSS 里。当时要给一组卡片加间距，我直接用了 flex 布局的新版 gap 属性，然后按惯例写了一个 margin 方案作为降级：

.card-list { display: flex; /* 基础方案：用 margin 模拟间距 */ .card + .card { margin-left: 12px; } } /* 新能力可用时，用 gap 接管 */ @supports (gap: 12px) { .card-list { gap: 12px; } }

看着没问题，但实际样式表里后面还有一个模块把.card的 margin 重新定义过，层叠顺序一压，基础降级方案被覆盖，旧环境里的间距全乱了。

正确做法是把“无 gap 环境”和“支持 gap 环境”的状态彻底分开：

.card-list { display: flex; } .card-list .card + .card { margin-left: 12px; } /* 支持 gap 时，清掉 margin 补偿，改用 gap */ @supports (gap: 12px) { .card-list .card + .card { margin-left: 0; } .card-list { gap: 12px; } }

这个坑教会我一件事：降级样式不能被后续样式牵着走，必须在语义上把“补偿用的样式”和“基础样式”剥离开，否则任何一个地方的覆盖都能让降级失效。

3.3 翻车现场三：降级分支里调用了“自以为存在”的功能

第三个坑藏得最深。当时某个上报模块在异常捕获后有一段兜底处理，代码大概是：

try { // 一些操作 } catch (e) { // 降级处理 sendReport(e); } function sendReport() { // 内部用了 Promise 的 finally 方法，旧环境里根本没有 fetch(url).finally(clearLoading); }

看起来 catch 分支是在'兜底'，但 sendReport 本身依赖了 Promise.prototype.finally，旧环境执行到这里照样抛错。而异常发生在 catch 里，连全局错误捕获都接不到，上报数据直接静默丢失，排查起来特别费劲。

这类问题的共性是：团队默认“降级分支 = 简单分支”，但实际上降级分支里的代码同样需要做保守语法约束。我后来给自己立了一条规矩：凡是降级路径，一律只用 ES5 语法和 BOM/DOM 基础 API，不允许出现任何需要额外转译或 polyfill 才能跑的东西。

3.4 把降级变成可管理清单

踩过这些坑之后，我养成了一个习惯：给每个项目维护一份“能力清单”，把项目依赖的新 API 和新 CSS 特性全部列出来，标注检测方式、降级方案和负责人。

有了这张表，每次新增功能时都能快速回答“这个能力在低版本环境里会怎样”，而不是等到用户报障再临时抱佛脚。

4. 渐进增强的道：从“没有 JS 也能读完整内容”的地基往上盖

4.1 三层金字塔：内容、表现、行为

渐进增强把网页拆成三个层次：内容层（HTML 语义结构）、表现层（CSS 视觉样式）、行为层（JavaScript 交互）。每一层都应当独立可用——JS 挂掉，内容还在；CSS 没加载，信息仍然有序；HTML 再朴素，关键标题、正文、链接、表单都还在。

这个金字塔的妙处在于，它是按“依赖强度”自下而上排列的：底层不依赖上层，上层只是在下层基础上的加分项。

我做内容站的时候验证过这个思路：关掉 JS 后，页面标题、段落、图片、导航链接都能正常阅读，用户可以靠锚点跳转和原生表单提交完成主要操作。在此基础上再谈懒加载、平滑滚动、动态筛选，所有增强都是“锦上添花”，而不是“雪中送炭”。

4.2 为什么现代前端又绕回了这条老路

前几年单页应用大行其道时，渐进增强一度被嫌弃“老土”，好像不提它就显得技术落后。结果移动端弱网、低端设备、搜索引擎爬虫一起来，大家发现还是老思路扎实——很多团队绕了一圈回来做 SSR、SSG，本质就是为了重新获得“没有 JS 也能看到完整内容”的兜底能力。

服务端渲染输出的 HTML 本身就是内容层，浏览器加载完后进行的 hydration 就是行为层的增强。这套模式能流行，正是因为它在工程化层面主动实现了渐进增强的核心思想：先把完整内容交给浏览器，再按能力选择性地“唤醒”交互。

理解了这一层，再看渐进增强的“术”，你会发现它其实是一套非常工程化的操作链路。

5. 渐进增强的术：特性检测、分层加载与媒体兜底的操作链

5.1 第一步：无 JS 环境下的内容与表单自检

落地渐进增强，第一件事不是写代码，而是做一次“裸奔测试”：把浏览器调试工具的 JavaScript 关掉，然后打开你的页面，看看会发生什么。

• 核心内容能不能完整阅读？
• 文章列表能不能靠链接正常跳转？
• 搜索、登录、评论这些操作有没有原生表单兜底？
• 图片有没有 alt 文本？

这一轮测试能暴露大量平时看不见的问题。比如很多按钮是<div>加 click 事件做的，JS 一关就完全无法操作；很多内容通过 JS 拉取渲染，关掉 JS 后整页是空的。这些问题要在渐进增强策略下尽早处理，因为它们是“内容层”的地基。

5.2 第二步：分层加载脚本，让老浏览器只拿到基础包

渐进增强的行为层，核心在于“不一次性把全套 JS 交给所有浏览器”。比较实用的做法是采用 module / nomodule 双模式：

<script type="module" src="/assets/app.modern.js"></script> <script nomodule src="/assets/app.legacy.js"></script>

支持 ES Module 的浏览器会加载并执行app.modern.js，自动忽略nomodule的脚本；不支持 ES Module 的老浏览器则会加载app.legacy.js。这套机制的妙处在于，本质上是“让浏览器自己选适合它的那份代码”。

配合打包工具，可以构建出两个入口：一个现代入口，只做语法转译但不做过多降级，代码体积小；一个兼容入口，严格转译到 ES5，并且只包含基础交互，代码体积大一些。现代浏览器拿到的是轻量增强包，老浏览器拿到的是保守基础包，两边各取所需。

5.3 第三步：媒体资源的渐进兜底

图片是内容型页面的大头，渐进增强在这里同样适用。用<picture>配合<source>，让浏览器按支持情况选择最优格式，同时永远保留一个最保守的兜底：

<picture> <source type="image/avif" srcset="img.avif" /> <source type="image/webp" srcset="img.webp" /> <img src="img.jpg" alt="一只猫在窗台上" /> </picture>

完全不认识新格式的浏览器会乖乖加载img.jpg，支持现代格式的浏览器自动选择体积更小、清晰度更高的来源。这不影响内容本身的可读性，但实实在在地帮用户省了流量、提升了加载速度。

5.4 第四步：把能力检测结果沉淀为一张运行时地图

渐进增强不等于到处写 if，更推荐在一开始就做一次集中的能力检测，把结果放进一张“运行时能力地图”里：

const capabilities = { intersectionObserver: 'IntersectionObserver' in window, fetch: 'fetch' in window, modules: (function () { try { new Function('import("")')(); return true; } catch (e) { return false; } })(), gap: window.CSS && CSS.supports('gap', '1rem') };

后续所有增强逻辑都从这张地图里取结果，而不是散落在各个文件里各自检测。好处是能力判断一目了然，排查问题的时候打开控制台看一眼capabilities对象，就知道当前环境支持到哪一层。

6. 回到现实项目：四个问题帮你决定往哪边走

6.1 先回答四个问题再定策略

理论说完了，回到最实际的问题：我的项目到底该选哪条路？我一般会先问四个问题：

1. 用户浏览器环境可控吗？内部后台、定制设备、封闭环境，环境相对可控，用优雅降级很务实；大众 C 端应用，你根本不知道用户用什么打开你的页面，渐进增强更稳妥。
2. 核心体验是内容消费还是高频交互？内容阅读、信息展示、门户首页这类场景，内容完整性优先，天然适合渐进增强；编辑器、控制台、数据填报这类工具，用户依赖完整交互，优雅降级反而更贴合真实使用方式。
3. 团队能维护两条路径吗？渐进增强的“双包模式”和分层结构需要一定的工程投入，如果前端只有一两个人，维护两套构建入口会很吃力。此时要么用优雅降级并严格收窄支持范围，要么借助构建工具自动处理分层，降低人工成本。
4. 现有技术债把哪条路的地基挖坏了？如果代码里已经全是“先实现，再临时补判断”的降级，硬要改成渐进增强等于一次重构；如果基础层已经比较干净，渐进增强的迁移成本反而更低。

6.2 一种更现实的混合打法：核心链路渐进增强，周边功能优雅降级

实际项目里很少有人非黑即白地只选一种。我现在的默认做法是：核心链路走渐进增强，周边体验走优雅降级。

以内容站为例：文章的阅读、目录跳转、图片查看、搜索提交，这些是核心链路，必须做到“无 JS 也能完成”，确保任何环境都不丢内容；侧边栏的动效、主题切换的过渡动画、首页的个性化推荐，这些是周边体验，直接按优雅降级来处理——环境支持就做花哨点，不支持就静默消失，绝不阻塞主流程。

这种混合打法的核心原则是：先给所有用户一个不残缺的底子，再在这个底子上分功能决定“要不要为了好看而冒险”。

6.3 兼容策略说明书：一个容易被忽略的工程产物

最后分享一个我觉得价值极高的习惯：不管选哪种策略，都写一份简短的“兼容策略说明书”，放进项目文档里。内容不用多，写清楚这三件事就够了：

• 支持到哪一代浏览器/内核，依据是什么（用户设备统计、客户合同要求等）；
• 哪些能力必须降级，哪些能力允许直接不支持；
• 当前策略选的是降级还是增强，未来什么情况下需要切换。

这份说明书最大的作用，是让后来接手的同事不用靠猜。很多兼容问题其实不是技术有多难，而是团队对“这个功能在旧环境里应该活成什么样”从来没有达成过共识。

就我个人而言，经历了那次白屏事故之后，我接到新项目第一件事不是翻代码，而是先找负责人问清楚用户环境和兼容底线。先把基准环境定下来，再谈优雅降级还是渐进增强——方向对了，后面每一步都不会偏太多。