rel="stylesheet"拼写错误或漏写会导致样式彻底失效；浏览器仅严格匹配该值才加载解析CSS，大小写、空格、引号均不可错，否则Network无请求、Computed为空、页面白屏或FOUC。
rel="stylesheet" 写错或漏写，样式就彻底消失
浏览器只认 rel="stylesheet" 这个精确值，大小写、空格、引号缺一不可。写成 rel="css"、rel=stylesheet（缺引号）、rel="StyleSheet"，文件照常下载，但不会解析、不参与 CSSOM 构建，页面白屏或 FOUC——控制台几乎不报错，只能靠 Network 面板看响应头是否返回 text/css，再反查 link 标签。
常见踩坑点：
-
href路径以 HTML 文件为基准，不是当前编辑器打开位置，也不是 CSS 文件所在目录 -
type="text/css"在 HTML5 中已冗余，加了不报错但无实际作用；仅当服务端未返回正确Content-Type时，它可能触发兼容 fallback - 多个
<link rel="stylesheet">按书写顺序加载，后加载的同选择器规则会覆盖前面的——顺序即优先级
link 必须放在 <head> 里，否则预加载和图标都失效
浏览器只在解析 <head> 阶段做早期资源发现（early resource discovery），<link rel="preload">、<link rel="preconnect">、甚至部分 <link rel="icon"> 若误塞进 <body>，Chrome/Firefox 可能“修复”CSS 加载，但预加载请求根本不会发出，Network 面板里完全看不到。
真实影响：
立即学习“前端免费学习笔记（深入）”；
-
<link rel="preload" as="font">放在<body>→ 字体加载延迟，文字闪动（FOIT/FOUT）加剧 -
<link rel="icon">在旧版 Safari 或 iOS 上可能不显示，尤其没配sizes和type时 - W3C 验证失败，CI/CD 流水线可能直接中断构建
favicon 多尺寸声明不是“锦上添花”，而是设备适配刚需
仅写 <link rel="icon" href="favicon.ico"> 能跑通 IE 和老 Chrome，但在现代高 DPI 屏、iOS PWA、Android 启动屏上，浏览器常默认取 16×16 像素，导致图标模糊成马赛克。这不是缓存问题，是尺寸决策逻辑本身缺失。
必须显式提供多尺寸，并用独立标签声明：
<link rel="icon" href="icon-16.png" sizes="16x16" type="image/png"><link rel="icon" href="icon-32.png" sizes="32x32" type="image/png"><link rel="icon" href="icon-192.png" sizes="192x192" type="image/png">
sizes="any" 对标准 rel="icon" 无效，那是给 rel="mask-icon"（Safari 固定标签页）用的；.ico 文件虽可打包多尺寸，但 Chrome 等主流浏览器仍优先读 sizes 属性做匹配，不能依赖内置尺寸自动识别。
preload 的 as 属性写错，等于没写
<link rel="preload"> 不是“保证加载”，而是告诉浏览器：“这个资源我马上就要，请按对应类型提升优先级”。as 值错配，浏览器就无法启用专用加载通道，降级为普通 fetch，失去提前 DNS 解析、高优先级队列等优化。
关键配对必须严格：
- 字体：用
as="font"，且跨域时必须加crossorigin，否则@font-face仍因 CORS 失败 fallback - CSS：用
as="style"，配合onload动态注入可避免阻塞渲染 - 图片：用
as="image"，若带fetchpriority="high"可进一步提示主图优先 - JS：用
as="script"，但注意它不执行，只是预拉取；真正执行仍需<script>标签
最容易被忽略的是：preload 本身不改变资源用途，它只是调度信号。一个 <link rel="preload" as="script"> 拉下来的 JS，若后续没有对应 <script src="...">，它就只是躺在内存里的一段二进制数据。
