应按复用频次与变更频率拆分CSS：高复用低变更的合并进基础包，低复用高变更的保持独立并加单元测试；同时用cacheGroups抽离第三方样式、动态加载业务样式、禁用@import链式引用。
全局 CSS 文件越积越大，build 速度和热更新明显变慢
当所有样式都塞进一个 index.css 或 app.css，Webpack/Vite 构建时需解析、压缩、注入整个文件，哪怕只改一行按钮颜色，也要重走完整流程。尤其在开启 css-loader 的 importLoaders 或启用 PostCSS 插件（如 autoprefixer、postcss-preset-env）时，单文件体积每增加 100KB，HMR 延迟可能多出 300–800ms。
实操建议：
- 用
splitChunks.chunks: 'all'+cacheGroups把第三方 UI 库样式（如ant-design/dist/antd.css）单独抽成vendor.css，避免每次业务修改触发其重新处理 - 对业务模块，按路由或功能域拆：比如
login.css、dashboard.css，配合import('./login.css')动态加载，确保未访问的样式不参与构建 - 禁用全局
@import链式引用——它会让构建器失去静态分析能力，导致无法 Tree-shaking 或误判依赖关系
CSS-in-JS 或 CSS Modules 为什么没解决维护成本问题
很多人以为换成 styled-components 或 emotion 就能“自动隔离”，结果发现组件复用时样式逻辑反而更难追踪：同一按钮在 Button.js 和 ModalFooter.js 中各自定义了 padding、border-radius，视觉不一致；而 :hover 状态散落在多个 JS 文件里，想统一调整交互反馈，得 grep 全项目。
关键矛盾在于：「作用域隔离」不等于「设计系统收敛」。真正降低维护成本的是约束，不是自由。
立即学习“前端免费学习笔记（深入）”；
实操建议：
- 保留 CSS Modules，但强制约定命名空间前缀，例如
class="btn_primary"而非class="primary"，避免跨组件语义冲突 - 把原子样式（颜色、间距、圆角）抽成
tokens.css，用:root定义 CSS 变量，JS 和 CSS 同时消费，改一个变量值就能同步所有地方 - 禁止在组件内写
style={{ color: '#333' }}内联样式——它绕过所有样式管理机制，是维护黑洞
如何判断该合并还是该拆分某块 CSS
没有银弹规则，只看两个硬指标：复用频次 & 变更频率。比如一个 table-layout.css，被 12 个页面 import，但过去半年只改过 1 次，就该合并进基础样式包；而 report-chart.css 只在报表页用，但每周都要调配色、改动画时长，就该保持独立并加单元测试（用 Puppeteer 截图比对）。
实操建议：
- 用
glob-import（Webpack）或import.meta.glob（Vite）批量收集样式引用关系，生成依赖图谱，识别“高引用低变更”和“低引用高变更”的模块 - 对拆分后的 CSS 文件，在
package.json的sideEffects字段显式声明，例如["*.css", "src/styles/*.css"]，否则 Webpack 可能误删未被 JS import 的样式文件 - 给每个 CSS 文件加头部注释，标明适用场景、最后修改人、关联 Jira 编号，例如：
/* @scope dashboard/widgets @changed-by @zhangsan @jira DASH-421 */
维护成本最常卡在「谁动了这个 class」——不是技术选型问题，是缺乏变更追溯机制。上线前跑一遍 git grep -n ".btn_secondary" src/，比争论“应该用 BEM 还是 CSS Modules”有用得多。
