拆分通用CSS与业务CSS可提升首屏性能、优化缓存策略、保障SSR一致性并支持tree-shaking；通用CSS应独立构建、稳定hash、服务端预置，业务CSS按需加载、动态引入、模块化作用域。
通用CSS和业务CSS混在一起会导致首屏加载变慢
浏览器解析 HTML 时，遇到 <link rel="stylesheet"> 就会阻塞渲染，直到 CSSOM 构建完成。如果把所有样式（包括框架组件、重置、工具类、业务页专属样式）打包进一个 app.css，这个文件体积很容易突破 300KB，尤其在中大型 SPA 中。用户首次访问时，哪怕只看首页，也得下载并解析整站所有 CSS，白屏时间明显拉长。
拆分后，通用部分（如 base.css、components.css）可设为 rel="preload" 或利用 HTTP/2 Server Push 提前送达；业务 CSS（如 home.css、profile.css）按需加载，配合路由懒加载，首屏关键 CSS 可压缩到 50KB 以内。
热更新和缓存失效范围失控
Webpack/Vite 默认对 CSS 做 contenthash，但一旦业务 CSS 和通用 CSS 打进同一个 chunk，改一行按钮颜色（.btn-primary { background: #007bff; }），整个 CSS 文件 hash 都变——导致用户端通用样式缓存全部失效，重复下载基础组件、字体图标等资源。
拆分后建议：
立即学习“前端免费学习笔记（深入）”；
- 通用 CSS 单独构建为
vendor.css，使用稳定的 hash（如 git commit hash 或语义化版本号） - 业务 CSS 按路由或模块生成独立 chunk，用 contenthash
- 在
index.html中显式引入vendor.css，其余由 JS 动态插入<link>
SSR 和 CSR 渲染一致性容易出问题
服务端渲染时若未同步注入当前页面所需的业务 CSS，客户端水合（hydration）后样式会闪动（FOUC）。而通用 CSS（如 Normalize、布局工具类）是全站共用的，服务端可安全预置；业务 CSS 则必须和当前路由精确匹配。
典型错误写法：import './Button.css'; 放在组件顶层 —— Webpack 会把它提升到 bundle 开头，服务端无法感知是否该注入。
正确做法（以 React + Next.js 为例）：
- 通用 CSS 在
_app.tsx中import 'styles/vendor.css'; - 业务 CSS 改为动态 import：
const HomePage = dynamic(() => import('./HomePage').then(m => ({ default: m.default })), { loading: () => <spinner></spinner>, ssr: true });，并在HomePage组件内用useEffect(() => { import('./HomePage.module.css'); }, []);（注意：仅限 CSR 场景；SSR 需配合styled-jsx或emotion的 SSR API）
Tree-shaking 和作用域污染难以兼顾
CSS 本身不支持原生 tree-shaking，但现代方案（如 CSS Modules、@vanilla-extract/css）依赖“模块化引入”才能生效。如果通用样式（如 reset.css）和业务样式写在同一个文件里，或通过全局 @import 引入，工具链就无法判断哪些类名实际被用到。
更隐蔽的问题是：团队多人协作时，有人在 utils.css 里加了个 .text-center，结果全站所有 <div class="text-center"> 都被影响——哪怕那个 div 根本不属于他的模块。
<p>拆分后可明确约束：</p>
<ul>
<li>通用层只提供原子类（如 <code>u-mt-2）、基础组件（Button, Modal）及其主题变量
@import 全局 CSS，必须用 CSS Modules 或 scoped stylepostcss-discard-comments + postcss-discard-duplicates 清理冗余规则真正难的不是拆，而是定义清楚“通用”的边界：比如一个带搜索框的导航栏，在 3 个页面复用算通用，但在第 4 个页面需要加筛选条件，这时要不要抽成独立组件？这类决策比技术实现更容易引发后期维护成本。别迷信“一次拆分永久省心”，每季度应 review 通用 CSS 的实际引用率，删掉半年没被 import 过的类名或组件样式。
