只有当第三方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”，文字显示为默认字体。
- 纯样式规则（颜色、布局等）不触发 CORS 检查，加不加都正常渲染
- 只加载 CSS 文件本身（
rel="stylesheet"）不强制要求crossorigin，除非它“带货”——即内嵌跨域字体或你后续要用 JS 读取document.styleSheets[n].cssRules -
link标签加了crossorigin，但字体服务端没返回Access-Control-Allow-Origin响应头，照样失败；属性只是“发起方式”，不是“放行开关”
crossorigin="anonymous" 和不写值的区别
写 crossorigin（无值）和 crossorigin="anonymous" 在行为上等价，但语义模糊：部分构建工具（如某些 Webpack 插件或 HTML 压缩器）会忽略无值写法，导致实际未生效。线上出问题时很难排查。
- 显式写
crossorigin="anonymous"是稳妥做法，明确告诉浏览器“走 CORS 流程，不带 Cookie” -
crossorigin="use-credentials"几乎不用——它要求服务端同时返回Access-Control-Allow-Origin: https://your-domain.com和Access-Control-Allow-Credentials: true，而公共字体 CDN（如 Google Fonts、Fontsource）根本不支持凭据模式 - 给
<link rel="icon">或<link rel="manifest">加crossorigin完全无效，浏览器直接忽略
怎么验证 crossorigin 是否起作用？
别只看 HTML 有没有写，重点查 Network 面板里字体文件（.woff2/.ttf）的请求头和响应头：
- 请求头必须含
Origin字段（说明已走 CORS 流程） - 响应头必须含
Access-Control-Allow-Origin: *或精确域名（如https://your-site.com） - 如果字体请求带查询参数（如
?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，浏览器跳过校验，哪怕文件被篡改也不会报警。
- 正确组合：
<link rel="stylesheet" href="https://cdn.example.com/style.css" crossorigin="anonymous" integrity="sha384-..."> - Webpack/Vite 构建的项目若用
import()动态加载 CSS（比如按需引入主题），也要确保 chunk 输出配置了crossOriginLoading: 'anonymous'或等效选项，否则动态加载的 CSS 里的字体照样失败
最易被忽略的是：字体文件本身是否在服务端配了 CORS，而不是 CSS 文件——很多人修了半天 HTML，最后发现是 CDN bucket 的 CORS 规则漏了一条 Allowed Origin。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
