link标签根本不存在blocking属性，W3C规范未定义，所有浏览器均忽略；真正控制CSS阻塞行为的是rel值（如stylesheet强制阻塞）和media查询匹配状态。
HTML中没有blocking属性
直接说结论：link标签根本不存在blocking这个属性，W3C规范里查不到，所有浏览器都不支持。如果你在代码里写了<link blocking rel="stylesheet" href="style.css">，它不会报错，但也不会起任何作用——浏览器会忽略这个未知属性，样式表依然按默认规则加载（即阻塞渲染），但你误以为加了“开关”反而放松了警惕。
真正控制CSS阻塞行为靠的是rel和media
CSS是否阻塞首次渲染（从而避免FOUC），取决于rel值和media查询是否匹配当前环境：
-
rel="stylesheet"：无条件阻塞渲染，直到CSSOM构建完成 —— 这是防FOUC的默认安全行为 -
rel="preload" as="style"+onload注入：不阻塞，需手动插入<style>或切换rel，否则必然FOUC -
media设为不匹配的值（如media="print"或media="(min-width: 9999px)"）：资源仍下载，但不参与渲染流程，不阻塞主渲染路径
想稳防FOUC，就别动“阻塞”，而是确保CSS尽早可用
阻塞本身不是问题，延迟才是。FOUC本质是HTML解析完、准备绘制时，CSS还没就绪。关键在缩短这个等待窗口：
- 把
<link rel="stylesheet">放在<head>最前面，越早声明越好 - 避免
@import，它会串行加载，放大阻塞时间 - 关键CSS内联（
<style>...</style>），非关键部分异步加载（用rel="preload"+ JS注入） - 启用HTTP/2服务端推送（若后端支持），对首屏关键CSS主动推送给浏览器
检查FOUC是否真的被避免，别信“写了就生效”
即使代码看起来正确，也常因这些原因悄悄出现FOUC：
立即学习“前端免费学习笔记（深入）”；
- 服务器启用了慢速网络模拟或高延迟响应，CSS返回耗时超过几百毫秒
- CDN缓存未命中，回源拉取CSS导致首屏加载变慢
- 使用了
rel="preload"但JS注入逻辑有竞态（比如onload没绑定或执行晚于DOMContentLoaded） - Chrome DevTools里开了“Disable cache”，但没关“Network Throttling”，误判本地加载速度
验证方式很简单：清空缓存 → 硬刷新 → 在Elements面板盯着<head>，看<link>变成已加载状态的时间点，是否早于DOMContentLoaded事件触发。
