link标签顺序直接决定样式是否生效，后加载的同权重规则无条件覆盖前面的；必须按reset→base→components→theme→page分层组织，禁用@import和preload误用，确保基础样式置前、覆盖样式置后。
link 标签顺序不是“写得整齐就行”，而是直接决定样式是否生效、首屏是否白屏、用户会不会看到 FOUC。顺序错，再好的 CSS 也白搭。
为什么 link 顺序一错就覆盖失效
浏览器按 HTML 中 link 出现的顺序，依次下载、解析、注入 CSSOM。后加载的同权重规则，无条件覆盖前面的——这不是“可能”，是渲染引擎的确定性行为。
- 常见现象：
h1 { color: red; }在base.css里写了，但页面显示蓝色；打开 DevTools → Styles 面板，发现被后面theme.css的同名规则划掉（strikethrough），且theme.css对应的link确实排在base.css后面 - 基础变量（如
:root里定义的--primary-color）必须在所有用到它的样式之前加载，否则变量取值为initial或继承值 - 重置样式（
reset.css）若放在组件样式之后，按钮边框、列表缩进等就根本没被归零，后续调整全在错误基础上叠加
link 应该按什么层级排，而不是按“名字字母序”
不能靠文件名排序，要按依赖关系和应用时机分层。基础层不稳，上层全塌。
-
基础层：重置（
reset.css）、工具类（utils.css）、字体与变量定义（fonts.css、vars.css）→ 必须最前，且彼此间也有依赖（如vars.css要在reset.css后？不，它应该最先，因为重置里可能用变量） -
功能层：布局（
layout.css）、通用组件（button.css、card.css）→ 紧跟基础层，按模块引用关系排（例如card.css用到了layout.css里的栅格类，那它就得放后面） -
响应式/条件层：媒体查询专用（
tablet.css、print.css）→ 用media属性声明，放在最后；media="print"不会阻塞屏幕渲染，但media="screen"和不写media效果一样，仍阻塞
哪些 link 写法看着对，其实埋了雷
很多写法语法没错，但实际效果和预期相反，尤其在构建产物或跨环境部署时。
立即学习“前端免费学习笔记（深入）”；
-
@import在 CSS 文件里出现 → 它把被导入内容“粘贴”到该行位置，并强制串行加载。哪怕main.css末尾写了@import 'theme.css';，实际加载顺序也是：base.css→main.css（不含 import 部分）→theme.css。彻底禁用，改用显式link - 相对路径写成
../css/lib.css→ 本地双击打开 HTML 时，浏览器按文件系统路径解析，../指向磁盘父目录，404；部署到服务器后才按 URL 解析。一律用根相对路径（/css/lib.css），但需确保服务端配置支持 -
rel="preload" as="style"单独写 → 它只下载，不应用。必须配onload="this.onload=null;this.rel='stylesheet'"才能切换为样式表；漏掉this.onload=null，JS 多次执行时会重复插入link
动态换肤或主题切换时，link 顺序怎么保得住
手动删旧 link、插新 link 很容易出竞态：旧样式还没卸载完，新样式已注入，导致部分元素用 A 主题、部分用 B 主题。
- 不要用
document.write或直接innerHTML替换head内容，会触发重排重绘甚至 DOM 重建 - 推荐做法：给每个主题
link加唯一id（如id="theme-light"），切换时先remove()旧的，再appendChild()新的；并在onload回调里触发事件，确保样式真正就绪后再更新 UI - 更稳妥的是预加载所有主题 CSS，只通过
disabled属性控制启用状态：<link id="theme-dark" rel="stylesheet" disabled>，切换时批量 toggledisabled，避免网络请求延迟
最容易被忽略的一点：所有这些顺序控制，都建立在浏览器线性解析 HTML 的前提下。一个没设 charset 的 meta、一段同步执行的 script、甚至 link 前面多了一个未闭合的注释，都可能让后续 link 的解析时机偏移几十毫秒——而这就是 FCP 超限的全部原因。
