rel="preload"预加载css必须配as="style"和onload动态改rel才能生效，否则仅下载不解析不应用；漏写as或onload会导致白屏、重复请求或csp拦截。
预加载 CSS 本身不能防止闪烁，必须配合 onload 切换 rel 属性才生效；漏掉 as="style" 或 onload，它就跟普通 <link> 一样阻塞或无效。
为什么 <link rel="preload"> 单独写没用
浏览器把 rel="preload" 当作“提前下载指令”，但不会自动解析或应用——它只是把文件拉进缓存，等着你手动触发。如果你只写：<link rel="preload" href="main.css">，那文件确实会早加载，但永远不会变成样式表，页面照样白屏/错位。
-
as="style"缺失 → 浏览器按普通资源调度，优先级低，甚至可能被降级 -
onload回调没写或写错 → 下载完不切换rel，CSSOM 始终不构建 - 放在
后半部分 → 预加载启动晚，失去“提前”意义
rel="preload" 的正确写法和执行链
核心是三要素缺一不可：声明预加载 + 指定资源类型 + 下载后激活。典型写法：
<link rel="preload" href="critical.css" as="style" onload="this.rel='stylesheet'">
-
as="style"告诉浏览器这是样式资源，参与渲染阻塞链的优先级调度 -
onload="this.rel='stylesheet'"是激活开关，触发 CSSOM 构建 - 必须放在
最前面，越早声明，预加载越早开始 - IE 不支持
preload，需降级：<link rel="stylesheet" href="critical.css">紧跟其后
preload 不是万能解药，它依赖关键 CSS 已存在
如果 critical.css 里混入了非首屏样式（比如 .footer、.modal），体积膨胀，加载延迟，FOUC 依然发生。更糟的是：构建工具抽离了 vendor.css 或用了 CSS-in-JS，critical.css 根本没覆盖真实首屏节点。
- 务必用
critters（Vite）、critical（CLI）或 Lighthouse 的 Coverage 面板提取真实首屏样式 - 移动端视口（如 375×667）下提取，避免 desktop-only 选择器污染
- 过滤掉
@font-face、@keyframes、display:none相关规则——它们不参与首屏绘制 - 移除对应外部
<link rel="stylesheet">，否则重复加载浪费带宽
比 preload 更可靠的是内联关键 CSS
rel="preload" 仍受网络延迟、CDN 跳数、HTTP/1.1 队头阻塞影响；而内联（<style>...</style>）绕过所有网络环节，是唯一 100% 可控的防闪手段。
- 只放真正首屏必需的选择器：
.header、.hero、基础重置、字体定义 - 体积控制在 10KB（gzip 前），否则可能阻塞 HTML 解析本身
- 别手写维护——用构建插件自动生成，否则上线后很快过期
-
preload只适合辅助加载剩余非关键 CSS，比如用media="print"+onload加载完整样式表
真正卡住首屏的从来不是“有没有 preload”，而是关键样式是否在首次绘制前就位；网络再快，内联缺失就一定会闪。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
