rel=preload 加载 CSS 会阻塞渲染吗？
不会——但有个关键前提：rel=preload 本身不执行 CSS，只下载；真正阻塞渲染的是后续 rel=stylesheet 的引入方式。很多人误以为加了 preload 就万事大吉，结果页面依然白屏卡顿，问题就出在这里。
- 必须配合
onload或media切换，否则预加载的 CSS 不会被应用 - 直接写
<link rel="preload" href="style.css" as="style">后不处理，浏览器下载完就丢弃，完全没用 - 如果同时存在普通
rel="stylesheet"引入同一文件，两个请求可能并行发起，浪费带宽
如何让 preload 的 CSS 安全、及时地生效？
核心是“下载完立刻挂载”，但不能破坏 DOM 渲染流程。最稳妥的做法是监听 load 事件后动态创建 link 标签，或用 media 属性做条件激活。
- 推荐方案：用
onload动态插入（兼容性好，Chrome 50+ / Firefox 48+ / Safari 11.1+）<link rel="preload" href="main.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
- 备用方案：初始设
media="print"，加载完成切回media="all"，避免 FOUC 和重复解析 - 不要在
onload里调用document.write()或操作未就绪的 DOM 节点，容易报错或失效
为什么有时 preload 反而变慢了？
常见于路径错误、MIME 类型不匹配或服务器未开启 HTTP/2。浏览器对 as="style" 有严格校验，一旦不满足，会退化为普通 fetch，失去优先级和预加载语义。
- 检查响应头是否包含
Content-Type: text/css，否则 Chrome 会忽略preload - 确保
href是绝对路径或相对于当前 HTML 的正确路径，相对路径出错时静默失败 - HTTP/2 下多个
preload可复用连接；HTTP/1.1 下可能因并发限制反而拖慢主样式加载 - Webpack/Vite 等构建工具生成的 CSS 文件名含 hash，
preload的href必须同步更新，否则 404
和 rel=preload 混用 rel=prefetch 有什么风险？
prefetch 是低优先级后台加载，目标是未来导航用的资源；而 preload 是高优先级、当前页必需。混用时若配置不当，会抢占带宽，延迟关键 CSS。
立即学习“前端免费学习笔记（深入）”；
- 不要对同一 CSS 文件同时写
preload和prefetch，浏览器行为未定义，部分版本会去重，部分会发两次请求 -
prefetch应只用于非首屏、用户行为可预测的资源（如点击“详情”后才需要的组件样式） - 移动端弱网下，
prefetch可能挤占主文档或关键 CSS 的 TCP 连接窗口，导致 TTFB 延长
href 没同步更新——它不会报错，只是静静加载一个 404，然后 fallback 到常规 link 加载，整个预加载逻辑彻底失效。 
