多个link rel="stylesheet"标签按HTML中顺序加载并层叠覆盖，后加载的同选择器规则覆盖前者；需严格控制顺序（重置→布局→组件→主题），避免路径错误、大小写不匹配、media误用及preload/prefetch混用。
多个 link rel="stylesheet" 标签会按顺序加载和覆盖
浏览器解析 HTML 时，遇到每个 link rel="stylesheet" 就发起一次 HTTP 请求（或复用缓存），且严格按它们在 <head> 中出现的顺序执行：后加载的 CSS 规则会覆盖前面同选择器的声明。这不是“合并”，而是层叠应用。
常见错误现象：reset.css 写在 theme.css 后面，结果重置规则把主题色全干掉了；或者 print.css 没加 media="print"，直接污染了屏幕样式。
- 确保加载顺序符合层叠意图：通用重置 → 基础布局 → 组件样式 → 主题/变体
- 避免用多个
link模拟“模块化”却忽略顺序依赖——button.css依赖vars.css？那就必须把后者放前面 - 不要指望浏览器自动合并请求：4 个
link= 最多 4 次独立请求（HTTP/1.1 下更明显）
href 路径写错或大小写不匹配导致样式静默失效
CSS 加载失败时，浏览器通常不报错，只跳过渲染——页面白屏、文字无样式、表格没边框，但控制台可能一片空白。根本原因常是 href 路径相对于 HTML 文件解析，而非 JS 或当前 CSS 文件。
使用场景：项目结构为 /index.html 和 /css/main.css，那么 href 必须写 "css/main.css"，不是 "./css/main.css"（虽多数浏览器容忍，但部分 SSR 或构建工具会严格校验）。
立即学习“前端免费学习笔记（深入）”；
- 路径必须区分大小写：Linux 服务器上
"CSS/style.css"≠"css/style.css" - 避免用
../跨太多级：容易在子目录页（如/blog/post.html）中解析失败 - 上线前用浏览器 Network 面板检查每个
link的 Status：404 或 403 就是路径或权限问题
用 media 属性做条件加载，别让打印样式拖慢首屏
media="print" 或 media="(max-width: 768px)" 的 link 标签，浏览器只在匹配条件时才下载并解析 CSS。这对性能很关键——你不需要让用户为打印样式付出首屏延迟。
性能影响：未匹配的 media 样式表仍会触发 DNS 查询和 TCP 连接（尤其跨域 CDN），但不会阻塞渲染，也不会执行 CSSOM 构建。
- 把
print.css放最后，且明确写media="print"，否则它会在所有设备上加载 -
media值必须是合法媒体查询字符串：写成media="screen and (min-width: 768px)"可以，但media="desktop"是无效值，会被当作all - 不要滥用
media实现“懒加载”：它不等价于 JS 动态插入，无法响应运行时尺寸变化
rel="preload" 和 rel="prefetch" 不能混用，关键资源要分清“现在就要”和“后面可能要”
想提前加载主样式表？用 rel="preload"；想为下一页预取 CSS？必须用 rel="prefetch"。两者语义和调度策略完全不同，混用等于白写。
容易踩的坑：把 main.css 同时用 preload 和普通 stylesheet 引入，反而触发重复下载；或在首页写 prefetch 指向登录页的 JS，结果用户根本没点登录，白白浪费带宽。
-
rel="preload"必须配as="style"，否则浏览器不识别为高优先级样式资源 -
rel="prefetch"的href应为绝对路径或根相对路径（如/assets/next-page.css），子路径（如./next.css）在不同页面下解析结果不可控 - 字体、首屏图标这类资源适合
preload；通用组件库、二级页面样式适合prefetch
真正难的是判断哪些 CSS 算“关键”——内联关键 CSS + 外链非关键部分，比堆一堆 link 更有效。而 link 标签本身不解决合并问题，它只是加载管道的入口；合并得靠构建工具或手动 concat，再通过单个 link 引入。
