link标签的crossorigin属性仅对CSS和字体两类资源生效，且必须与服务端Access-Control-Allow-Origin等响应头严格匹配；其他资源如icon、manifest、image preload均无效，错误使用会破坏加载逻辑。
link 标签的 crossorigin 属性在多 CDN 场景下**不提升安全性，也不控制资源加载权限**，它只影响特定资源（CSS、字体）的跨域访问能力，且必须和服务端响应头严格配对才生效；加错地方或配错值反而会破坏加载逻辑。
哪些 CDN 资源的 link 标签真需要 crossorigin
只有两类资源在跨域加载时，crossorigin 才有实际作用：
-
<link rel="stylesheet" href="https://cdn-a.com/main.css">：想用 JS 读取document.styleSheets[n].cssRules时必须加crossorigin="anonymous"，否则返回null或抛SecurityError -
<link rel="preload" as="font" href="https://cdn-b.com/font.woff2">：确保字体能被@font-face正确绑定并渲染，否则可能 fallback 到系统字体
其他常见多 CDN 场景全无效：
-
<link rel="icon" href="https://cdn-c.com/favicon.ico" crossorigin>→ 浏览器静默忽略，不影响加载 -
<link rel="manifest" href="https://cdn-d.com/manifest.json" crossorigin>→ 不触发 CORS，也不校验 integrity -
<link rel="preload" as="image" href="https://cdn-e.com/photo.jpg" crossorigin>→ 规范不支持as="image"，属性被丢弃，图片仍按普通非 CORS 方式加载
crossorigin="use-credentials" 在多 CDN 中极易翻车
除非你明确知道某个 CDN 上的 CSS 或字体受登录态保护（比如内网私有字体服务），否则一律不要用 use-credentials。它在多 CDN 场景下风险极高：
立即学习“前端免费学习笔记（深入）”；
- 只要任意一个 CDN 域名没配
Access-Control-Allow-Credentials: true，该资源就静默失败，页面无报错、样式不生效、字体不加载 - 服务端若返回
Access-Control-Allow-Origin: *，浏览器直接拒绝响应（*和use-credentials互斥） - 多个 CDN 同时用
use-credentials，等于要求每个服务端都满足三重响应头：Access-Control-Allow-Origin（精确域名）、Access-Control-Allow-Credentials: true、Access-Control-Allow-Headers（如需预检）
绝大多数公共 CDN（jsDelivr、unpkg、Cloudflare Pages）根本不支持凭据模式，硬配只会让资源白屏。
integrity 必须和 crossorigin 配套才起效
多 CDN 引入第三方库时，integrity 是防篡改的关键，但它只在 CORS 流程成功后才校验：
-
<link href="https://cdn-a.com/bootstrap.css" integrity="sha384-xxx" crossorigin="anonymous">→ 先走 CORS 请求，成功后再比对 hash，校验通过才应用样式 -
<link href="https://cdn-a.com/bootstrap.css" integrity="sha384-xxx">（没crossorigin）→ 浏览器跳过 integrity 校验，哪怕文件被 CDN 中间人篡改也照常加载
常见错误是只加 integrity 却漏掉 crossorigin，尤其在多 CDN 混用时，不同资源维护者配置不一致，导致部分资源校验失效。
真正容易被忽略的是：CDN 域名变更（比如从 cdn-a.com 切到 cdn-b.com）后，服务端 CORS 响应头往往没同步更新，crossorigin 就从“保障”变成“阻断”。每次切 CDN，必须验证 Network 面板里对应请求是否返回了匹配的 Access-Control-Allow-Origin，不能只看 HTML 里有没有写属性。
