CSS加载顺序、media属性控制、禁用@import、关键CSS内联是性能优化四大核心。顺序决定层叠覆盖，media实现条件加载，@import导致串行阻塞，critical CSS内联+异步加载保障首屏速度。
多个 <link rel="stylesheet"> 的加载顺序直接影响样式生效结果
浏览器按 HTML 中出现的顺序依次解析 CSS 文件，后引入的样式会覆盖前面同名规则（层叠规则）。所以顺序不是“怎么写都行”，而是直接决定最终渲染效果。比如基础重置样式必须在组件样式之前，否则 normalize.css 里的 button { margin: 0; } 就可能被后面某处 button { margin: 8px; } 覆盖掉。
- 基础样式（如
reset.css或normalize.css）必须排第一 - 通用工具类（如
utils.css、variables.css）紧随其后，供后续文件引用变量或 class - 布局与组件样式（如
grid.css、button.css）放在中间，依赖已声明的基础和工具 - 页面专属样式（如
home.css）放最后，确保能覆盖通用规则
media 属性不是可选装饰，而是关键的加载控制开关
把所有 CSS 都无差别加载到首屏，是性能翻车的常见起点。浏览器遇到 <link rel="stylesheet" media="print"> 时，会异步加载且不阻塞渲染；而 media="(max-width: 768px)" 在不匹配时也暂不下载——这比 JS 动态判断更早介入资源调度。
- 打印样式用
media="print"，完全不影响屏幕渲染流程 - 响应式断点样式建议用
media而非 JS 切换，避免样式闪动 - 慎用
media="screen"：它等价于不写，但显式写出容易误导团队以为做了优化 - 不要对关键首屏样式加
media，否则可能因媒体查询未即时匹配而延迟加载
别把 @import 和 <link> 混着用
@import 在 CSS 文件内部使用，会触发串行请求：浏览器必须先下载并解析完前一个 CSS，才能发现里面的 @import 并发起下一个请求。而多个 <link> 是并行加载的。混用时，哪怕只在一个 base.css 里写了 @import "theme.css"，整个链路就从并行退化为串行。
- 构建工具（如 Webpack、Vite）打包时，
@import通常会被内联或转成<link>，但开发阶段若直接手写，风险仍在 - 开发者工具 Network 面板中看到 CSS 请求明显拉长、呈阶梯状，大概率是
@import作祟 - 如果必须复用某份 CSS，优先用构建时 import，而非运行时
@import
关键 CSS 内联 + 其余异步加载才是现代实践底线
纯靠 <head> 里一堆 <link> 已不够用。首屏必需的样式（如 header、hero 区块）应提取为 critical CSS，内联进 <style>；其余非关键 CSS 用 <link rel="preload" as="style" onload="this.onload=null;this.rel='stylesheet'"> 异步加载。否则，哪怕顺序再合理，大体积 CSS 仍会拖慢首次绘制。
立即学习“前端免费学习笔记（深入）”；
- 内联部分要严格控制大小，超过 14KB 可能触发 HTTP/1.1 分包，反而更慢
- 异步加载的 CSS 不会阻塞渲染，但插入 DOM 后仍会触发重排重绘，注意避免影响交互帧
- 服务端渲染（SSR）场景下，critical CSS 提取需配合模板逻辑，不能只靠构建脚本
media 控制条件加载、或者误用了 @import。这些点不处理，光调顺序没用。 
