link blocking="render" 是让 变成渲染阻塞资源的行为，即浏览器在该资源加载、解析（如 css）完成前不绘制任何像素，导致白屏；目前仅 rel="stylesheet"、rel="preload"（配合 as="style" 或 "font"）和 rel="modulepreload" 支持，且需位于 中，chrome 125+ 支持，firefox/safari 尚未实现。
link blocking="render" 是什么行为
它让 <link> 变成渲染阻塞资源：浏览器在该资源加载、解析（如 CSS）、甚至执行（如 rel="stylesheet"）完成前，**不绘制任何像素到屏幕上**。不是暂停 HTML 解析，而是冻结画面输出 —— 用户看到的是白屏或上一页面残留，直到这个 <link> 就位。
哪些 rel 值支持 blocking="render"
目前只有三类 <link> 能真正触发渲染阻塞：
-
rel="stylesheet"：最常用，CSS 加载未完成时禁止渲染 -
rel="preload"：仅当as="style"或as="font"等关键类型时，配合blocking="render"才会阻塞（注意：as="image"不会） -
rel="modulepreload"：用于预加载 ES 模块，但需搭配type="module"
其他如 rel="icon"、rel="preconnect" 写了 blocking="render" 会被浏览器忽略 —— 它们本身就不参与渲染流程。
为什么不能只靠 defer 或 async 替代
defer 和 async 是针对 <script></script> 的，对 <link> 无效；而传统 <link rel="stylesheet"> 虽默认阻塞渲染，但缺乏显式语义。问题在于：
- 团队协作时，别人可能误删或改成
rel="preload"，导致白屏变 FOUC - 动态插入的
<link>（比如 JS 创建后 append 到）默认不阻塞，加blocking="render"才能恢复原生阻塞行为 - 模块化场景下，
<link rel="modulepreload">默认不阻塞，必须显式声明blocking="render"才能保证样式/字体就绪后再出帧
容易踩的坑和兼容性提醒
这个属性很新，2024 年中才开始进入稳定版 Chrome（125+），Firefox 和 Safari 尚未实现。实操时要注意：
- 不要单独依赖它做关键路径保障 —— 仍要保留传统
<link rel="stylesheet">作为降级 -
blocking="render"必须写在中，放在里无效 - 它不改变资源优先级，建议同步加
fetchpriority="high"确保调度及时 - 服务端返回的 CSS 若
Content-Type错误（如application/octet-stream），即使加了blocking，旧版 Safari 仍拒绝解析，白屏无解
真正关键的不是加不加这个属性，而是你是否清楚：哪个 CSS 必须阻塞、哪个图标可以异步、哪个 preload 其实根本没用上 —— blocking 只是把意图写进 HTML 的一种方式，而不是性能银弹。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
