CSS文件数量多本身不致命，真正拖慢首屏的是多个<link rel="stylesheet">同时参与初始CSSOM构建；解决关键是控制首屏渲染所用CSS（内联关键CSS），其余通过media="print"+onload异步加载，而非挪至</body>底部或盲目合并。
直接说结论：CSS 文件数量多本身不致命，真正拖慢首屏的是「多个 <link rel="stylesheet"> 同时参与初始 CSSOM 构建」。解决不是靠删文件，而是控制哪些 CSS 参与首屏渲染、哪些延迟加载。
为什么把 <link> 挪到 </body> 底部是错的
浏览器解析 HTML 是顺序执行的，<link rel="stylesheet"> 出现在哪一行，就卡在哪一行——哪怕它在 </body> 前最后一行，HTML 解析器走到它时仍会暂停，等 CSSOM 构建完才继续。更糟的是，此时 DOM 已基本完成，但没样式，用户看到 FOUC（无样式内容闪现），且后续 JS 调用 getComputedStyle 或 offsetHeight 会读到错误值。
旧版 Safari 还可能因此触发重排；Webpack/Vite 输出的 <link> 若被手动移到底部，会破坏资源优先级和缓存复用逻辑。
用 media="print" + onload 实现零 JS 兼容异步
这是目前最轻量、兼容性最好的方案，IE11 都能跑通。原理是浏览器对 media="print" 的样式默认懒处理：下载不阻塞 HTML 解析，也不参与初始 CSSOM。
立即学习“前端免费学习笔记（深入）”；
<link rel="stylesheet" href="non-critical.css" media="print" onload="this.media='all'; this.onload=null;">-
onload中必须立刻执行this.media='all'，否则样式永不生效 - 必须加
this.onload=null，否则旧版 Safari 可能重复触发 - IE 不支持
onload，需 fallback 到onreadystatechange（loadCSS库已内置） - 别用
media="(min-width: 9999px)"这类假条件，2026 年起部分浏览器已拒绝识别
用 rel="preload" + onload 预加载关键但非首屏 CSS
适合你明确知道某份 CSS 会在交互后立即用到（比如深色主题 dark.css 或弹窗组件 modal.css），想提前下载但不让它干扰 LCP。
<link rel="preload" href="dark.css" as="style" onload="this.rel='stylesheet'; this.onload=null;">-
as="style"必须写，否则 Chrome/Firefox 不提升优先级，甚至忽略预加载 -
href值要和最终<link rel="stylesheet">完全一致（含 query 参数），否则缓存不复用 - 务必配
<noscript><link rel="stylesheet" href="dark.css"></noscript>，覆盖禁 JS 场景和 Safari 11.1 以下 - 动态创建
<link>时，onload在 Firefox 69 之前和部分 Android WebView 中不可靠，建议用loadCSS库或 fallback 到onreadystatechange
合并 CSS 文件时最容易踩的坑
合并不是“越多越好”，关键在区分场景：基础重置、工具类、全局组件样式可合并；路由专属、A/B 测试、用户主题类 CSS 必须拆开。
- 手动拼接容易出错：@import 无法被静态分析，相对路径（如
url(../fonts/icon.woff)）在合并后基准目录变化，需重写为绝对路径 - Vite 用户注意
build.rollupOptions.output.manualChunks分组逻辑，避免把admin/dashboard.css和首页样式打到同一个 chunk 导致缓存失效 - Webpack 中若用
MiniCssExtractPlugin，需配合optimization.splitChunks.cacheGroups强制归入同一 chunk，否则可能仍拆成多个文件 - HTTP/2 下仍建议合并——TLS 握手、TCP 慢启动、服务器 I/O 开销不会因多路复用消失；单个文件更新导致整个包缓存失效，比拆分后仅更新一个文件代价更大
内联首屏关键 CSS 比折腾异步更重要：如果首屏样式体积小于 2KB，直接塞进 <style> 标签里，省掉一次网络请求，效果立竿见影。其他所有优化都是在此基础上的补充。
