获课：xingkeit.top/5251/

样式按需加载方案：拆分蘑菇街多页面 CSS，消灭冗余代码

蘑菇街这类电商平台，页面数量动辄上百——首页、商品详情、购物车、订单、用户中心，每个页面都有独立的样式。早期做法是把所有 CSS 打成一个大文件，首屏加载时一股脑全塞给浏览器。结果就是：用户打开首页，却要下载购物车页面的样式。带宽浪费，首屏变慢，FCP 指标直接爆炸。

样式按需加载，就是解决这个问题的关键一刀。

问题的本质：一个页面不该背负所有页面的样式

传统打包方式下，所有页面的 CSS 被合并成一个 bundle。这个 bundle 随着业务增长只会越来越大。蘑菇街的核心页面加上活动页、营销页，CSS 体积轻松突破几百 KB。用户首屏只需要当前页面的样式，其余的都是负担。

更隐蔽的问题是样式冗余。不同页面可能用了同一套基础组件，但因为打包在一起，无法复用。比如按钮样式，首页有、详情页有、订单页也有，三份几乎一样的代码被重复打包了三次。

方案一：路由级别的代码分割

最直接的做法是按路由拆分 CSS。每个页面对应一个 CSS chunk，路由切换时才加载对应的样式。

Vue Router 和 React Router 都支持路由级别的动态导入。页面组件加载时，同步加载它的 CSS 文件。未访问的页面，样式根本不会出现在网络请求里。

这个方案的好处是实现简单，侵入性低。但缺点也明显：如果两个页面共用大量样式，拆分后会导致重复下载。比如首页和活动页都用了同一套弹窗组件，两个页面各自加载一份弹窗样式，就是浪费。

方案二：组件级别的样式隔离

比路由拆分更细粒度的方案，是把样式下沉到组件级别。每个组件自带样式，只在组件被渲染时才注入。

Vue3 的 <style scoped> 天然支持这个模式。Webpack 或 Vite 会给每个组件的样式生成独立的 chunk，配合异步组件加载，实现真正的"用哪个组件，加载哪个样式"。

但组件级别拆分有个坑：公共样式会被分散在各个组件的 chunk 里，导致首屏请求数暴增。十个组件就是十个 CSS 请求，HTTP 开销反而变大。

解决办法是把公共样式单独提取出来，作为基础包在首屏加载，业务样式按需加载。这样既避免了冗余，又控制了请求数。

方案三：关键 CSS 内联 + 非关键 CSS 异步

这是性能收益最大的方案，也是蘑菇街这类大厂的实际做法。

核心思路是：把当前页面渲染必须的 CSS 提取出来，直接内联到 HTML 的 <style> 标签里，首屏渲染不需要任何网络请求。其余非关键样式（比如用户中心的设置页样式、订单页的评价样式）通过 <link rel="preload"> 异步加载。

怎么判断哪些是关键 CSS？工具层有 Critical 库可以自动提取，也可以在构建阶段通过分析路由匹配关系，预先生成每个页面的关键 CSS 快照。

这个方案的优势是首屏最快，因为关键路径上零网络请求。代价是构建配置复杂，每个页面都要维护一份关键 CSS 快照，页面新增时需要同步更新。

蘑菇街的实际选择：三层拆分策略

蘑菇街这类体量的项目，通常不会只用一种方案，而是三层组合：

第一层：基础样式全局打包。 重置样式、字体、栅格系统、颜色变量，这些所有页面都需要，打包成一个基础包，首屏必加载。

第二层：页面级别按需加载。 每个业务页面的独有样式，拆成独立 chunk，路由切换时加载。

第三层：组件级别懒加载。 弹窗、抽屉、图片预览这类低频组件的样式，只在组件首次渲染时才注入。

三层配合，既保证了首屏速度，又消灭了冗余代码，还控制了请求数。

怎么判断方案有没有效果

别只看 CSS 总体积，要看三个指标：首屏 CSS 体积（关键 CSS 内联后通常在 20KB 以内）、样式请求数（首屏不超过 2 个）、缓存命中率（公共基础包一旦缓存，后续页面切换零样式请求）。

这三个指标都达标，才算真正做到了样式按需加载。

总结

样式按需加载不是一种技术，而是一种思维——用户当前看不到的样式，就不该让浏览器下载。 蘑菇街的实践证明，按路由拆分解决了"加载不需要的样式"的问题，按组件拆分解决了"重复打包公共样式"的问题，关键 CSS 内联解决了"首屏渲染阻塞"的问题。

三管齐下，CSS 体积能砍掉六成以上，首屏 FCP 提升一个档次。样式优化的回报，比你想象的大得多。