应采用作用域隔离与明确依赖的模块化方案：优先CSS-in-JS或CSS Modules，纯CSS则遵循BEM、分离base/utils、构建工具管理合并与导入。
多个 CSS 文件怎么组织才不乱
直接把样式拆成 header.css、button.css、modal.css 看似模块化，实际容易失控：类名冲突、覆盖顺序难维护、开发时找不到样式在哪改。真正可行的模块化不是靠文件数量，而是靠作用域隔离和明确的依赖关系。
推荐用 CSS-in-JS（如 styled-components）或支持作用域的预处理器（如 PostCSS + css-modules）。如果必须用纯 CSS，至少做到：
- 每个模块文件只导出一个 BEM 风格的根类名，例如
.card，内部子元素用.card__title、.card--large - 禁止在模块文件里写全局重置（
body、h1）、通用工具类（.text-center），这些统一收口到base.css和utils.css - 用
@import或构建工具（如 Webpack 的css-loader）管理依赖顺序，别靠 HTML 中标签顺序硬控优先级
合并 CSS 文件真能提升性能吗
能，但前提是「合并后不显著增大单个文件体积」且「缓存策略合理」。HTTP/2 下多小文件的队头阻塞问题已缓解，盲目合并反而可能降低缓存复用率——比如 admin.css 和 landing.css 共用 30% 样式，合并成一个文件会导致用户访问任一页面都得下载全部。
更务实的做法是按路由或功能域切分，并用构建工具动态合并：
- Webpack 中用
MiniCssExtractPlugin配合splitChunks，让公共样式（如common.css）单独提取，页面独有样式内联或懒加载 - Vite 项目默认启用 CSS 拆分，
import './Button.css'会自动收集并去重，无需手动合并 - 避免手写
cat a.css b.css > all.css这类操作——没有 source map、无压缩、无法 tree-shake 无用样式
如何避免 @import 引发的性能陷阱
@import 在 CSS 文件中是同步阻塞的，浏览器发现它会暂停当前样式表解析，发起新请求，等导入完成才继续。一个 main.css 里写了 5 个 @import，就等于串行加载 5 次，比并行 慢得多。
替代方案很明确：
- 构建阶段处理：用 PostCSS 插件
postcss-import把@import提前展开成内联内容，最终输出一个扁平化的 CSS 文件 - 开发阶段禁用
@import：所有样式入口统一由 JS 控制，例如import './styles/main.css'，交由打包器处理依赖 - 实在要用（如兼容旧系统），确保
@import写在文件最顶部，且只导入同域资源；禁止嵌套@import（A 导入 B，B 再导入 C）
要不要用 CSS 模块（CSS Modules）
要，尤其当项目有多个开发者或长期迭代。原生 CSS 的全局作用域是协作灾难源：.btn 被谁改了？为什么 .sidebar 在某个页面变宽了？CSS Modules 通过构建时哈希类名（如 Button_button__aBc12）天然隔离样式，同时保留写法简洁性。
注意几个落地细节：
- Webpack 中启用
css-modules后，必须用import styles from './Button.module.css'，再通过className={styles.button}使用，不能直接写className="button" - 需要局部覆盖时，用
:global(.third-party-class)显式声明全局作用域，避免误伤外部库样式 - 服务端渲染需同步生成 class 名映射，否则首屏和客户端 class 不一致导致样式闪烁
模块化不是文件越多越好，也不是合并越狠越快；关键在控制作用域、理清依赖链、让每次修改的影响范围可预期。很多团队卡在「不知道该拆还是该合」，其实问题不在策略，而在缺少构建层的自动化约束——一旦放开手写 和 @import，再好的设计也会退化。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
