跨域引入CSS失败是因为浏览器静默丢弃样式内容，必须服务端返回Access-Control-Allow-Origin响应头，前端crossorigin仅声明CORS请求模式；Nginx需用location精确匹配.css和字体后缀并加always、Vary:Origin等头，@import因不支持crossorigin必然失效，须改用带crossorigin的link标签。
跨域引入 CSS 失败，不是资源没拿到，而是浏览器静默丢弃样式内容——必须由服务端返回正确的 Access-Control-Allow-Origin 响应头，前端加 crossorigin 只是配合声明请求模式，单靠它解决不了问题。
为什么加了 crossorigin 还是没样式？
因为 crossorigin 本身不放行，只告诉浏览器“按 CORS 流程加载”。如果服务端响应里没有 Access-Control-Allow-Origin，浏览器就会把 CSS 内容当作“不透明响应”丢弃，控制台可能只报 No 'Access-Control-Allow-Origin' header is present，但 Network 面板里能看到状态码是 200 —— 说明文件收到了，只是被 CSS 引擎拒绝解析。
Nginx 配置 CSS 跨域头的关键写法
不能在 server 全局加，也不能只配 Access-Control-Allow-Origin。必须用 location 精确匹配 CSS 文件，并带上 always 标志防止 304 响应丢失头：
location ~* \.css$ {-
add_header Access-Control-Allow-Origin "https://your-app.com" always;（生产环境禁用*，尤其用了withCredentials） -
add_header Vary "Origin" always;（避免 CDN 缓存污染） add_header Access-Control-Allow-Methods "GET" always;-
try_files $uri =404;（终止后续处理，防止被其他 location 拦截）
字体等子资源也被拦截怎么办？
CSS 里 @font-face 或 background-image: url() 加载的字体、图片，会触发独立的跨域请求，且比主 CSS 更严格。它们失败时控制台报错更明确，比如：
立即学习“前端免费学习笔记（深入）”；
Font from origin 'https://cdn.example.com' has been blocked from loading by Cross-Origin Resource Sharing policy
这时要单独为字体后缀配 location：
location ~* \.(woff2?|ttf|eot|otf|svg)$ {add_header Access-Control-Allow-Origin "https://your-app.com" always;add_header Access-Control-Allow-Methods "GET" always;
注意：正则必须覆盖你实际用到的所有后缀；CDN 若有缓存，需确认它透传源站的 add_header，否则配置无效。
@import 跨域 CSS 为什么一定失败？
因为 @import 不支持 crossorigin 属性，也不触发 CORS 协商。即使服务端返回了正确响应头，浏览器在解析阶段仍视其为“不透明响应”，直接跳过加载和解析，控制台报错但 Network 里可能看不到请求。唯一可靠方式是改用：
<link rel="stylesheet" href="https://cdn.example.com/style.css" crossorigin="anonymous">
并且确保该 URL 对应的服务端已配好 CORS 响应头——这才是真正起作用的一环。
真正卡点永远在服务端：前端能做的只是声明意图，能否生效全看响应头是否完整、精准、被缓存系统正确传递。漏掉 Vary: Origin、用错通配符、没加 always、或字体路径没单独配规则，都会让配置形同虚设。
