标签仅在加载受登录态保护的私有跨域资源（如需 cookie 鉴权的私有 css 或字体）时才真正需要 crossorigin="use-credentials"，此时服务端必须严格返回精确 access-control-allow-origin 域名和 access-control-allow-credentials: true，否则加载静默失败；普通公共资源一律用 anonymous 或不加。
哪些 <link> 场景真正需要 crossorigin="use-credentials"
绝大多数 <link> 标签根本用不到 use-credentials。它只在极少数明确要求携带登录态的跨域资源加载中才必要，比如：
-
<link rel="stylesheet" href="https://cdn.example.com/private.css">—— 但该 CSS 文件受服务端 session 或 cookie 鉴权保护（极少见，通常应走 token 或同域代理） -
<link rel="preload" as="font" href="https://fonts.example.com/secret.woff2">—— 字体托管在需登录才能访问的私有 CDN 上（比方说企业内网字体服务）
普通公共字体（Google Fonts）、开源 CSS 库（Bootstrap CDN）、静态样式表，一律用 crossorigin="anonymous" 或不加即可。加 use-credentials 不仅多余，还会因服务端配置稍有偏差直接导致资源加载失败。
crossorigin="use-credentials" 对服务端响应头的硬性要求
这个值不是“可选配置”，而是触发浏览器最严格校验的开关。只要前端写了它，服务端必须同时满足以下三条，缺一不可：
- 返回
Access-Control-Allow-Origin: https://your-domain.com（必须是精确协议+域名，*会被浏览器直接忽略） - 返回
Access-Control-Allow-Credentials: true（漏掉这行，控制台报Response to preflight request doesn't pass access control check） - 若请求触发预检（例如带自定义 header），
Access-Control-Allow-Headers必须包含实际发送的字段
常见错误：Nginx 配置里写了 add_header Access-Control-Allow-Origin *;，又配了 use-credentials → 浏览器静默丢弃响应，样式不生效，控制台无明显错误提示，排查成本极高。
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
<link rel="stylesheet"> 加了 use-credentials 却读不到 CSS 规则？
即使样式成功加载并渲染，JavaScript 仍无法通过 document.styleSheets[n].cssRules 访问规则内容——这不是 bug，而是 CORS 凭据模式下的安全限制。原因在于：
-
crossorigin="use-credentials"启用的是完整 CORS 模式，但浏览器对跨域样式表的 DOM API 访问权限依然受限 - 即便服务端返回了全部正确响应头，
cssRules仍会返回null或抛SecurityError - 这是规范行为，不是配置遗漏；想动态操作样式规则，必须把 CSS 放到同域，或改用
fetch()+new CSSStyleSheet()注入
为什么 <link rel="icon"> 加 crossorigin 完全无效
HTML 规范明确限定：crossorigin 属性只对 rel="stylesheet"、rel="preload"（且 as 值为 font、script、style 等特定类型）生效。给 <link rel="icon"> 加任何 crossorigin 值：
- 浏览器完全忽略，不发起 CORS 请求
- 不会触发预检
- 也不会影响 favicon 加载逻辑或错误捕获
如果遇到跨域 favicon 加载失败，问题一定出在服务器返回 403/404 或路径错误，跟 crossorigin 无关。强行加上去只会干扰调试直觉。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
