根本原因是服务端未返回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。
- 常见假象：CSS 文件明明能点开、状态码是 200，但页面样式就是不生效
- 本地双击 HTML（
file://协议）时，连响应头都不存在，必然拦截 - 混用
http页面加载httpsCDN 的 CSS，会触发net::ERR_BLOCKED_BY_CLIENT（混合内容）
CDN 必须返回正确的 CORS 响应头，前端加 crossorigin 属性没用
<link rel="stylesheet" href="https://cdn.example.com/style.css" crossorigin> 这个 crossorigin 属性，**只影响错误是否触发 onerror 回调，完全不能绕过 CORS 限制**。它对 CSS 加载行为本身无任何放行作用。
- 真正起效的只有服务端响应头：
Access-Control-Allow-Origin: https://yourdomain.com（生产环境别用*，尤其当涉及字体或凭证时） - 必须同步设置
Vary: Origin，否则 CDN 缓存可能把带 CORS 头的响应错误地返回给非跨域请求 - 部分 CDN（如早期 jsDelivr）对
.css路径默认支持 CORS，但托管在自定义域名下的 CSS 仍需手动配头
另一个高频原因：服务端没返回 Content-Type: text/css
即使 CORS 头齐全，如果 CDN 或源站返回的响应头里没有 Content-Type: text/css，浏览器也会直接拒载——这是比 CORS 更底层的拦截条件。
立即学习“前端免费学习笔记（深入）”；
- Nginx 场景：确认配置中包含
include mime.types;，且mime.types文件里有text/css css;这一行 - Node.js/Express 场景：别用
res.send(cssString)，改用res.type('css').send(...)或直接托管express.static() - 检查 Network → Response Headers →
Content-Type，值必须是text/css，不能是application/octet-stream或text/plain
真正卡住的点往往不在前端代码里，而在 CDN 控制台 HTTP 响应头配置是否生效、Nginx MIME 映射是否完整、以及 Content-Type 和 Access-Control-Allow-Origin 是否同时正确——漏掉任意一个，CSS 就会无声无息地消失。
