浏览器直接拦截标签的http css请求，因https页面中http资源属主动混合内容，浏览器在发起请求前就策略性阻断，network面板显示blocked:mixed-content。
浏览器拦截 <link> 标签，不是代码写错了，而是它触发了某条硬性安全策略——最常见的是混合内容（mixed-content）、SRI 校验失败、或 CORS 配置错位。这些拦截不报 JS 错误，也不进 window.onerror，只在 Network 面板里冷冰冰标一个 blocked:mixed-content 或静默丢弃资源。
为什么 <link rel="stylesheet"> 请求直接被拦，连 404 都不显示？
这是主动混合内容（Active Mixed Content）的典型表现：HTTPS 页面里写了 href="http://cdn.example.com/style.css"，浏览器在 TCP 连接建立前就终止请求，Network 面板里 Status 明确显示 blocked:mixed-content。
- 不是路径问题，也不是服务器没响应，是协议层面被策略性拦截
-
//cdn.example.com/style.css（协议相对 URL）同样危险：如果页面通过 HTTPS 加载，但 CDN 的 HTTP 端点不可用或重定向到 HTTP，仍会触发拦截 - 第三方 CSS 内部的
@import url("http://...")或background: url("http://...")也会被拦，且出现在子请求里，Initiator 列可反查源头 - 本地开发时用
https://localhost:3000加载页面，却引用线上http://xxx.com/style.css，一样触发
<link integrity> 失效却不报错，怎么确认它真在起作用？
SRI（Subresource Integrity）校验是“全有或全无”：失败就丢弃整个资源，不解析、不渲染，但控制台只有一条极简错误：The resource ... was blocked because integrity check failed，且无法用 JS 捕获。
- 必须同时满足三个条件才启用校验：
rel="stylesheet"+integrity属性 + 显式crossorigin="anonymous"（不能只写crossorigin或留空） -
rel="preload"、rel="icon"、as="style"等写法不支持 SRI，加了也白搭 - 哈希必须基于目标 URL 实际返回的字节流生成，不是你本地文件。CDN 可能压缩、重定向、加 BOM，导致本地算的
integrity值失效 - 可靠命令：
curl -sL https://cdn.example.com/style.css | openssl dgst -sha384 -binary | openssl base64 -A
<link crossorigin> 加了却没用，是不是配错了？
crossorigin 对 <link> 标签本身不触发脚本错误捕获，它只在两类场景生效：读取 CSSOM（如 document.styleSheets[0].cssRules）或预加载跨域字体（配合 integrity）。其他情况加了等于没加。
-
rel="icon"、rel="manifest"加crossorigin会被浏览器直接忽略——它们根本不走 CORS 流程 - 字体预加载必须配
as="font"+crossorigin="anonymous"，否则 @font-face 仍会因 CORS 失败 fallback 到系统字体 - 想让 JS 错误堆栈带行列号，该盯的是
<script crossorigin="anonymous"></script>和构建工具的 chunk 配置（如 Webpack 的output.crossOriginLoading），不是<link>
真正难排查的，是那些不报错、不提示、只让样式消失或图标不显示的拦截——比如 integrity 少写一个 crossorigin，或者 sizes 和 PNG 文件真实像素对不上，浏览器就默默跳过整条 <link>。验证永远要靠 Network 面板看实际请求和响应头，而不是只信 HTML 里写了什么。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
