多个标签会触发多次http请求，每个都是独立请求，http/1.1下导致tcp排队，http/2下仍需单独解析与cssom构建，增加首屏延迟；顺序错位则按源顺序覆盖同权重样式，须严格遵循reset→base→components→theme顺序。
多个 <link> 标签会触发多次 HTTP 请求
每个 <link rel="stylesheet"> 都是一个独立的网络请求，浏览器不会自动合并或复用。10 个 CSS 文件 = 至少 10 次 TCP 连接（HTTP/1.1 下）或至少 10 次流复用（HTTP/2），但依然有解析、下载、阻塞渲染的开销。
常见错误现象：页面首屏加载明显变慢，Network 面板里看到一堆 css 请求排队，尤其在弱网或高延迟环境下更明显。
- 开发阶段保留多文件利于模块化协作，但上线前必须评估请求数量
- HTTP/2 虽支持多路复用，但每个
<link>仍需单独解析和 CSSOM 构建，不能省掉“加载 → 解析 → 合并层叠”流程 - 移动端 3G 网络下，5 个以上 CSS 文件可能让 FCP（首次内容绘制）延迟超过 2s
顺序错位会导致样式覆盖失效
CSS 层叠规则不是“谁先加载完谁生效”，而是“谁写在后面，同权重下谁赢”。theme.css 放在 reset.css 前面，哪怕它体积小、加载快，里面的 h1 { margin: 2rem; } 也会被后面的 reset.css 覆盖掉。
典型盲区：改了 components.css 里的按钮颜色，但页面没变——打开开发者工具的 Computed 面板，点击属性值旁的文件名链接，常发现实际生效的是 base.css 或更早的文件。
- 标准顺序建议：
reset.css→base.css→layout.css→components.css→theme.css -
media属性不改变加载顺序，只控制是否应用：比如<link href="print.css" media="print">仍会下载，但不参与屏幕样式层叠 - 不要依赖 JS 动态插入
<link>来“修正顺序”，它绕过预加载，必然导致 FOUC
路径错误或 404 不报错，但样式彻底丢失
浏览器对缺失的 CSS 文件非常沉默：Failed to load resource: the server responded with a status of 404 () 只出现在 Console，页面本身不会提示、不会降级、不会 fallback。用户看到的就是裸 HTML，你却可能以为“只是样式没写好”。
相对路径尤其危险：HTML 在 /pages/user.html，而 <link href="css/style.css"> 实际查找的是 /pages/css/style.css，不是项目根目录下的 /css/style.css。
- 推荐统一用根路径：
/css/reset.css，避免因 HTML 所在层级不同导致路径漂移 - 构建工具（如 Vite）中用
import './theme.css'是安全的，因为编译后自动转为正确路径的<link> - 检查方式：Network 面板过滤
css，看所有请求状态码是否都是 200；右键“Open in new tab”确认能直接访问该 URL
用 @import 替代 <link> 会串行阻塞
有人图省事，在 <style></style> 块里写 @import "a.css"; @import "b.css";，结果发现页面白屏时间变长——@import 是 CSS 规则，不是 HTML 标签，它在解析时强制串行加载，且无法被浏览器预加载器识别。
IE6–8 对 @import 的支持也不稳定，哪怕现在没人用，遗留系统维护时仍可能踩坑。
-
@import只应在 CSS 文件内部使用（如main.css里引入变量），不能放在 HTML 的<style></style>中 -
<link>是并行下载，@import是“下载 a → 解析 a → 发现 import b → 下载 b”，链式等待 - 现代项目若用 Sass/Less，
@import是编译期行为，不产生运行时请求，和这里说的 CSS runtime@import不是一回事
<link> 的排列，要习惯用 Computed 面板反向追踪每条样式从哪来。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
