如何使用crossorigin属性加载第三方CSS

只有当第三方CSS内含跨域字体（@font-face）时才必须加crossorigin，否则仅样式渲染不受影响；加了也需服务端返回Access-Control-Allow-Origin响应头才生效。

什么时候必须加 crossorigin 才能加载第三方 CSS？

只有当第三方 CSS 文件内部引用了跨域字体（@font-face）时，才真正需要 crossorigin。浏览器渲染样式本身不依赖它，但一旦 CSS 里有 src: url(https://cdn.example.com/font.woff2) 这类跨域字体声明，且没配 crossorigin，字体就会被拦截，控制台报“No 'Access-Control-Allow-Origin' header is present”，文字显示为默认字体。

1. 纯样式规则（颜色、布局等）不触发 CORS 检查，加不加都正常渲染
2. 只加载 CSS 文件本身（rel="stylesheet"）不强制要求 crossorigin，除非它“带货”——即内嵌跨域字体或你后续要用 JS 读取 document.styleSheets[n].cssRules
3. link 标签加了 crossorigin，但字体服务端没返回 Access-Control-Allow-Origin 响应头，照样失败；属性只是“发起方式”，不是“放行开关”

crossorigin="anonymous" 和不写值的区别

写 crossorigin（无值）和 crossorigin="anonymous" 在行为上等价，但语义模糊：部分构建工具（如某些 Webpack 插件或 HTML 压缩器）会忽略无值写法，导致实际未生效。线上出问题时很难排查。

1. 显式写 crossorigin="anonymous" 是稳妥做法，明确告诉浏览器“走 CORS 流程，不带 Cookie”
2. crossorigin="use-credentials" 几乎不用——它要求服务端同时返回 Access-Control-Allow-Origin: https://your-domain.com 和 Access-Control-Allow-Credentials: true，而公共字体 CDN（如 Google Fonts、Fontsource）根本不支持凭据模式
3. 给 <link rel="icon"> 或 <link rel="manifest"> 加 crossorigin 完全无效，浏览器直接忽略

怎么验证 crossorigin 是否起作用？

别只看 HTML 有没有写，重点查 Network 面板里字体文件（.woff2/.ttf）的请求头和响应头：

1. 请求头必须含 Origin 字段（说明已走 CORS 流程）
2. 响应头必须含 Access-Control-Allow-Origin: * 或精确域名（如 https://your-site.com）
3. 如果字体请求带查询参数（如 ?v=2.1），确认 CDN 缓存策略透传了 CORS 头——很多 CDN 默认不缓存响应头，导致带参请求没返回 Access-Control-Allow-Origin

常见陷阱：Nginx 配置写了 add_header Access-Control-Allow-Origin *;，又用了 crossorigin="use-credentials"，浏览器直接静默丢弃响应，连错误都不报。

搭配 integrity 时必须加 crossorigin

integrity 属性校验资源完整性（SRI）的前提是资源已通过 CORS 加载成功。如果只写 integrity 不加 crossorigin，浏览器跳过校验，哪怕文件被篡改也不会报警。

1. 正确组合：<link rel="stylesheet" href="https://cdn.example.com/style.css" crossorigin="anonymous" integrity="sha384-...">
2. Webpack/Vite 构建的项目若用 import() 动态加载 CSS（比如按需引入主题），也要确保 chunk 输出配置了 crossOriginLoading: 'anonymous' 或等效选项，否则动态加载的 CSS 里的字体照样失败

最易被忽略的是：字体文件本身是否在服务端配了 CORS，而不是 CSS 文件——很多人修了半天 HTML，最后发现是 CDN bucket 的 CORS 规则漏了一条 Allowed Origin。