根本原因是JS动态插入的link绕过预加载器，未进入渲染阻塞链；唯一可靠解法是内联关键CSS（≤10KB、无media、置于head顶部），非关键CSS用media="print" onload="this.media='all'"异步加载并配noscript兜底。
异步加载 CSS 出现样式闪动（FOUC），根本不是“加载慢”，而是关键样式没在首屏渲染前就绪——浏览器已经画完一遍无样式的页面，才把 CSS 补上，必然重绘。
为什么 document.head.appendChild(<link rel="stylesheet">) 一定会闪
这种写法绕过了 HTML 解析器的预加载机制。预加载器（preload scanner）只扫描初始 HTML 字符串，对 JS 动态插入的 <link> 视而不见。等组件 mount、useEffect 或 mounted 触发时，DOM 和首屏早已渲染完毕，此时插入样式表等于“事后补妆”，浏览器只能强制重排重绘。
- DevTools Network 面板里，这类
<link>的 Initiator 列显示为other或script，而不是parser，说明它根本没进阻塞链 - SSR 场景下更明显：服务端没输出该
<link>，客户端 JS 补上就是肉眼可见的跳变 - 哪怕加了
rel="preload"，如果没配as="style"或漏掉onload回调，也不会自动转为stylesheet
media="print" + onload 是最稳的异步加载姿势
它让浏览器并行下载 CSS，但不应用；等加载完成再切换 media 值，样式瞬间生效，不触发重排。
- 写法必须是：
<link rel="stylesheet" href="non-critical.css" media="print" onload="this.media='all'"> - 必须配
<noscript><link rel="stylesheet" href="non-critical.css"></noscript>，防 JS 失效导致样式完全丢失 - 不要用
media="(min-width: 768px)"这类条件判断来“控制加载时机”——浏览器会直接跳过加载，等匹配时再发起请求，反而延迟 - IE 不支持
onload，需降级：同一文件写两遍，第二遍去掉media="print"和onload
关键 CSS 必须内联或 preload，不能靠“放 head 里”蒙混过关
只把 <link> 放在 <head> 开头，不代表它真能阻塞渲染。若 media 不匹配、含 @import、或服务端返回 Content-Type: text/plain，浏览器都会把它当异步资源处理。
立即学习“前端免费学习笔记（深入）”；
- 验证是否真被阻塞：Network → 筛选
css→ 看 Initiator 是否为parser；不是，说明没进阻塞链 - 内联关键 CSS 要 ≤ 10KB，且注意转义：CSS 中若含未转义的
</style>（比如注释里写了/* */），会导致 HTML 解析中断 - 用 Chrome Coverage 面板或
critical工具提取首屏必需样式，别靠肉眼猜；响应式断点、@media (prefers-color-scheme)必须显式声明，否则提取结果漏掉暗色模式规则 - Vite/Webpack 默认开启
css.codeSplit，可能把同一组件的基础样式和主题样式拆到不同文件，导致关键 CSS 提取不全
真正难调的不是某一行代码写错，而是多个问题共存：PostCSS 插件顺序错位、content 路径漏扫、JS 注入时机延迟、甚至 CDN 域名不一致导致预加载缓存失效——它们都表现为“闪一下”，但根因完全不同。先清缓存、再验提取结果、最后盯住 Network 的 Initiator 列，别跳步。
