CSS项目结构混乱？按功能拆分更清晰

CSS项目结构混乱的根源往往不在于拆分本身，而在于错误地将功能模块直接暴露为多个独立CSS文件引入HTML——这会引发加载阻塞、依赖失控、缓存失效和样式丢失等连锁问题；真正高效且可维护的方案是：开发阶段按功能逻辑（如按钮、表单、网格）拆分为Sass/Less模块（_buttons.scss等），再通过@use等现代构建工具在编译期精准合并为单一main.css，既保持代码组织清晰、复用可控，又确保运行时性能最优、加载可靠——一句话：拆在源码里，合在构建中。

为什么直接按功能拆分 文件反而更乱

很多人一看到 CSS 越来越难维护，第一反应是“把按钮样式、表单样式、导航样式各自抽成 button.css、form.css、nav.css，再用多个 引入”——这看似合理，实际会触发浏览器并发加载限制、CSSOM 构建阻塞叠加、缓存失效粒度太细等问题。更关键的是，HTML 中一堆 标签会让加载顺序和依赖关系完全不可控，比如 utils.css 里的 .clearfix 被 card.css 依赖，但加载晚了，就可能漏掉样式。

真正有效的“功能拆分”发生在构建阶段，不是 HTML 阶段

你应该保留单个 （如 ），但让这个 main.css 是由多个功能模块文件拼出来的。工具链才是关键：

• 用 @import（不推荐，已废弃倾向）或现代方案如 PostCSS @import 插件 / Sass @use / Less @import 来组织源码结构
• 所有功能文件（_buttons.scss、_forms.scss、_grid.scss）只在开发时存在，构建后合并为一个压缩后的 main.css
• 确保变量、mixin、函数等基础层（_variables.scss、_mixins.scss）被最先导入，避免作用域错误

@use 'base/variables' as *;
@use 'base/mixins';
@use 'components/buttons';
@use 'components/forms';
@use 'layout/grid';

哪些功能模块值得单独成文件？看复用性和变更频率

不是所有“功能”都该拆。判断标准很简单：这个样式块是否满足以下任一条件？

• 被三个以上页面或组件引用（如 .badge、.tooltip）
• 有独立的交互状态逻辑（hover/focus/active/disabled 的完整组合）
• 内部包含媒体查询断点适配，且这些断点与其他模块不一致
• 团队中不同人负责不同业务区，需要隔离修改影响（如营销页的 .promo-banner 和后台的 .admin-table）

反例：_header.css 如果只在首页用、没复用、也没状态变化，就不值得单独文件——它应该属于 _page-home.scss 或直接内联到对应组件里。

上线后仍有多余 ？检查构建产物和 HTML 模板

如果线上 HTML 还出现多个 ，大概率是构建配置或模板写死了引入逻辑。常见原因：

• Webpack 的 MiniCssExtractPlugin 没配置 chunkFilename 合并策略，导致每个 chunk 都输出 CSS
• Vue/React 项目里用了