crossorigin属性仅声明走CORS流程，不等于跨域成功；必须服务端对CSS及其中所有url()子资源（如woff2、png）均返回Access-Control-Allow-Origin响应头，否则字体或背景图加载失败。
crossorigin 属性不是给 CSS “开绿灯”的开关，它只告诉浏览器：这个 要走完整的 CORS 协商流程加载。真正决定能否成功的是服务端返回的 Access-Control-Allow-Origin 响应头——没这个头，加了 crossorigin 也白加。
为什么加了 crossorigin 还报 No 'Access-Control-Allow-Origin' header？
典型现象是控制台报错，但页面样式看起来正常， 标签本身没标红。这是因为：
- 主 CSS 文件可能被当作“简单请求”加载成功（不触发预检），所以样式生效了
- 但 CSS 内部的
@font-face、background-image: url(...)等子资源，会在后续单独发起跨域请求 - 这些子资源请求会严格校验 CORS，而服务器没对
.woff2、.png等静态文件返回Access-Control-Allow-Origin - 结果就是字体加载失败、背景图空白，控制台报 CORS 错误
crossorigin="anonymous" vs crossorigin="use-credentials"
绝大多数场景用 crossorigin="anonymous" 就够了：
-
crossorigin="anonymous"：请求带Origin头，服务端必须返回Access-Control-Allow-Origin: *或精确匹配域名 -
crossorigin="use-credentials"：请求带Origin+ Cookie，服务端必须返回Access-Control-Allow-Origin: https://your-domain.com（不能是*）且Access-Control-Allow-Credentials: true - 不写值（
）等价于anonymous，但建议显式写出，避免歧义
@import 无法使用 crossorigin，必须改用
@import 语法本身不支持声明 crossorigin，而且浏览器不会为它触发 CORS 协商——这意味着它加载的跨域 CSS 中所有 url() 子资源都会静默失败。
- 哪怕服务端配好了所有 CORS 响应头，
@import引入的 CSS 里的字体、图片照样 403 或被拦截 - 唯一可靠方案是把
@import全部替换成带crossorigin的 - 如果 CSS 是由第三方 SDK 注入的（比如某些 UI 库的动态加载逻辑），需检查其是否支持传入
crossorigin配置
关键点容易被忽略：CORS 对 CSS 的影响是“传染性”的——crossorigin 不只管那个 CSS 文件本身，它会让整个样式表里所有 url() 调用都进入跨域校验流程。服务端必须对 .css、.woff2、.jpg 等所有相关资源统一配置响应头，漏配任意一类，就可能在某个看似无关的样式细节上出问题。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
