应保留单个<link>标签，通过构建工具（如Sass @use）将功能模块（_buttons.scss等）编译合并为一个main.css，避免HTML中多link引发的加载阻塞、依赖失控与缓存问题。
为什么直接按功能拆分 <link> 文件反而更乱
很多人一看到 CSS 越来越难维护，第一反应是“把按钮样式、表单样式、导航样式各自抽成 button.css、form.css、nav.css，再用多个 <link rel="stylesheet"> 引入”——这看似合理，实际会触发浏览器并发加载限制、CSSOM 构建阻塞叠加、缓存失效粒度太细等问题。更关键的是，HTML 中一堆 <link> 标签会让加载顺序和依赖关系完全不可控，比如 utils.css 里的 .clearfix 被 card.css 依赖，但加载晚了，就可能漏掉样式。
真正有效的“功能拆分”发生在构建阶段，不是 HTML 阶段
你应该保留单个 <link>（如 <link href="/assets/main.css" rel="stylesheet">），但让这个 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 或直接内联到对应组件里。
立即学习“前端免费学习笔记（深入）”；
上线后仍有多余 <link>？检查构建产物和 HTML 模板
如果线上 HTML 还出现多个 <link href="*.css">，大概率是构建配置或模板写死了引入逻辑。常见原因：
- Webpack 的
MiniCssExtractPlugin没配置chunkFilename合并策略，导致每个 chunk 都输出 CSS - Vue/React 项目里用了
<style src="./xxx.css">且未启用 CSS 提取插件 - HTML 模板中手动写了多个
<link>，而构建脚本没做清理（比如用html-webpack-plugin但inject: false） - 第三方 SDK 自己插入了
<link>（如某些统计或客服组件），需检查其文档是否提供禁用样式注入的选项（如disableCss: true）
最稳的做法：打开浏览器 DevTools → Network → 刷页面 → 看 CSS 请求是否只有 1 个（或按需的 2 个：主样式 + 字体图标等极少数异步资源），其余全是 304 或 from disk cache。
