link blocking="render" 不生效，因该属性未被html规范采纳，所有主流浏览器均忽略它；实际控制渲染阻塞应使用media、preload+onload或动态插入等成熟方案。
link blocking="render" 实际是否生效
不生效。当前（2026年7月）所有主流浏览器（Chrome 127+、Firefox 128、Safari 17.5）均**未实现** blocking 属性对 <link> 元素的支持，无论设为 render 还是其他值，该属性都会被忽略。
原因很直接：<link rel="stylesheet"> 本身默认就是渲染阻塞的——浏览器遇到它就会暂停 HTML 解析、等待 CSS 下载并构建 CSSOM，再继续渲染。加 blocking="render" 属于冗余声明，没有行为变更，也不触发任何新逻辑。
你能在 DevTools 的 Network 面板看到该请求的 Initiator 是 parser，这说明它已是关键阻塞资源；加了 blocking 不会让它“更阻塞”，也不会改变优先级或加载时机。
为什么 MDN 和规范里查不到 blocking 属性
因为 blocking 属性目前**未被纳入 HTML 规范正式草案**，也未被 WHATWG 或 W3C 标准化。MDN 上没有任何关于 blocking 的文档条目，CanIUse 亦无数据支持。
所有声称支持该属性的博客或教程，基本源自早期 Chromium 实验性 flag（如 chrome://flags/#enable-blocking-attribute）的误传，或对 <script></script> 中同名实验属性的错误泛化。实际生产环境代码中写 <link blocking="render">，只是多了一个无效的自定义属性。
容易踩的坑包括：
- 误以为加了就能控制加载时机，结果首屏仍白屏，却没去查真正的问题（比如 CSS 文件体积过大、未内联关键样式）
- 在构建工具或 SSR 模板中硬编码该属性，导致 HTML 体积无谓增加，且误导后续维护者
- 和
fetchpriority="high"混用，以为能叠加效果——但后者只影响网络调度，与渲染阻塞无关
真正能控制 link 渲染阻塞的行为有哪些
想让 <link> 不阻塞渲染，靠的是已有、稳定、广泛支持的机制，不是靠尚未落地的 blocking：
- 用
media属性匹配非当前环境：例如<link href="print.css" rel="stylesheet" media="print">，浏览器根本不会下载它，自然不阻塞 - 用
<link rel="preload" as="style" onload="this.rel='stylesheet'">异步加载 CSS，配合内联<style></style>提供首屏样式 - 把非关键 CSS 拆出来，用 JavaScript 动态插入（
document.head.appendChild(link)），此时它默认不阻塞渲染 - 避免在
中写多个<link rel="stylesheet">，尤其不要在关键 CSS 后面紧跟另一个——后者会延迟首次绘制（FCP）
注意：rel="preload" 必须配 as="style"，否则浏览器不会按样式表预加载；onload 回调里要立即改 rel，否则样式不会应用。
script 元素上的 blocking="render" 也别乱用
虽然 Chromium 曾短暂支持过 <script blocking="render"></script>（仅限 type="module" + async 组合），但它在 2025 年底已被移除。当前所有稳定版浏览器中，该组合行为等价于不加 blocking —— 即模块脚本仍异步执行，不阻塞渲染。
真正需要阻塞渲染的 JS，老办法更可靠：
- 同步脚本（无
async/defer）放在尾部，紧挨着关键 CSS 后 - 或把逻辑内联进
<script></script>，确保它参与初始渲染树构建（比如设置document.documentElement.classList）
试图用未标准化的属性去“精细控制”，反而会让代码变成兼容性黑洞——它既不能解决问题，又掩盖了真实瓶颈所在。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
