link rel=”preload” 加载 css 无效主因是 as 属性错误、mime 类型不匹配或服务端重定向；需显式设 as=”style”、确保 content-type: text/css，并配合 onload 动态切换为 stylesheet 才生效。
为什么 link rel="preload" 加载 CSS 有时没效果
浏览器对 link rel="preload" 的资源类型校验很严格：如果 as 属性写错，或 href 指向的不是实际 CSS 文件（比如带了服务端重定向、MIME 不匹配），它就只会下载，不会执行解析和应用。常见现象是 Network 面板里看到请求完成，但样式没生效，控制台也没报错。
-
as必须显式写成as="style"，不能省略或写成as="script" - 确保后端返回的响应头包含
Content-Type: text/css，尤其在用 Webpack Dev Server 或某些 CDN 时容易被覆盖 - 不要对内联
<style></style>或@import场景用 preload —— 它只管下载，不处理解析顺序
preload 和 onload 配合加载 CSS 的正确写法
单纯 preload 只触发下载，要让它真正“上屏”，得手动创建 link 标签并插入 DOM。关键点在于时机：不能等 load 事件，而要用 onload 回调监听预加载完成。
- 必须用
rel="preload"+as="style"触发提前下载 - 在
link.onload回调里新建一个link[rel="stylesheet"]，复用原href，再append到head - 记得加
link.onerror处理失败，否则样式丢失无提示
<link rel="preload" href="main.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
这行代码本质是把 onload 逻辑内联了，但更推荐 JS 控制——便于统一错误监控和 fallback。
和 rel="prefetch"、rel="preload" 混用时的优先级陷阱
浏览器对 preload 资源的优先级高于 prefetch，但若多个 preload 同时存在，且目标是 CSS，它们会按 HTML 中出现顺序竞争带宽，而非并行高优。更麻烦的是：如果某个 preload 的 CSS 文件体积大、响应慢，它会阻塞后续同优先级资源（包括其他 preload 的 CSS）的解析调度。
立即学习“前端免费学习笔记（深入）”；
- 别对非首屏关键 CSS 用
preload，它会挤占主文档和关键 JS 的带宽 - 避免对同一 CSS 文件既
preload又prefetch，后者会被忽略，还可能触发重复请求（取决于浏览器实现） - 移动端弱网下，
preload下载未完成前，后续link[rel="stylesheet"]仍会发起二次请求 —— 需靠 HTTP 缓存或 Service Worker 拦截规避
兼容性与 SSR 场景下的真实限制
preload 在 Chrome 50+、Firefox 54+、Safari 11.1+ 支持，但 Safari 对 onload 的支持直到 iOS 12.2 才稳定；SSR 渲染时，若服务端提前注入了 preload 标签，客户端 hydration 阶段可能因资源已缓存而跳过 onload，导致样式不挂载。
- 服务端渲染需配合客户端检查
document.styleSheets是否已含目标 CSS，避免重复插入 - Webpack 用户注意：
html-webpack-plugin的preload: true默认不加as="style"，必须手动配hints插件或 template 修改 - Next.js / Nuxt 等框架内置的 CSS 分离机制，通常已做优化，强行加
preload反而可能破坏其提取逻辑
最常被忽略的一点：CSS 文件的 ETag 或 Last-Modified 头缺失时，即使 preload 成功下载，浏览器也可能拒绝复用缓存，导致二次请求 —— 这个链路不在前端可控范围内，得盯住运维配置。