为什么跨域CDN上的CSS被浏览器拦截

根本原因是服务端未返回Access-Control-Allow-Origin响应头且缺失Content-Type:text/css，浏览器静默丢弃样式；需CDN配置CORS头（含Vary:Origin）与正确MIME类型，前端crossorigin属性仅影响onerror触发，无法绕过限制。

跨域 CDN 上的 CSS 被浏览器拦截，不是因为请求没发出去，而是浏览器拿到响应后主动丢弃了样式内容——根本原因是服务端没返回 Access-Control-Allow-Origin 响应头，且该 CSS 请求触发了 CORS 校验边界。

为什么 CSS 跨域会静默失败，控制台却没报错？

CSS 的跨域加载不走完整 CORS 流程（不发 OPTIONS 预检），但浏览器仍会校验响应头。一旦服务端响应中缺失 Access-Control-Allow-Origin，浏览器就拒绝将样式应用到页面，同时不抛出明显错误，只在 Network 面板里显示“Failed to load resource”或空 Preview。

1. 常见假象：CSS 文件明明能点开、状态码是 200，但页面样式就是不生效
2. 本地双击 HTML（file:// 协议）时，连响应头都不存在，必然拦截
3. 混用 http 页面加载 https CDN 的 CSS，会触发 net::ERR_BLOCKED_BY_CLIENT（混合内容）

CDN 必须返回正确的 CORS 响应头，前端加 crossorigin 属性没用

<link rel="stylesheet" href="https://cdn.example.com/style.css" crossorigin> 这个 crossorigin 属性，只影响错误是否触发 onerror 回调，完全不能绕过 CORS 限制。它对 CSS 加载行为本身无任何放行作用。

1. 真正起效的只有服务端响应头：Access-Control-Allow-Origin: https://yourdomain.com（生产环境别用 *，尤其当涉及字体或凭证时）
2. 必须同步设置 Vary: Origin，否则 CDN 缓存可能把带 CORS 头的响应错误地返回给非跨域请求
3. 部分 CDN（如早期 jsDelivr）对 .css 路径默认支持 CORS，但托管在自定义域名下的 CSS 仍需手动配头

另一个高频原因：服务端没返回 Content-Type: text/css

即使 CORS 头齐全，如果 CDN 或源站返回的响应头里没有 Content-Type: text/css，浏览器也会直接拒载——这是比 CORS 更底层的拦截条件。

1. Nginx 场景：确认配置中包含 include mime.types;，且 mime.types 文件里有 text/css css; 这一行
2. Node.js/Express 场景：别用 res.send(cssString)，改用 res.type('css').send(...) 或直接托管 express.static()
3. 检查 Network → Response Headers → Content-Type，值必须是 text/css，不能是 application/octet-stream 或 text/plain

真正卡住的点往往不在前端代码里，而在 CDN 控制台 HTTP 响应头配置是否生效、Nginx MIME 映射是否完整、以及 Content-Type 和 Access-Control-Allow-Origin 是否同时正确——漏掉任意一个，CSS 就会无声无息地消失。