根本原因是服务器返回的Content-Type响应头不是text/css，现代浏览器（如Chrome 90+）会严格校验该值，即使CSS内容正确，只要Header不符就拒绝解析并报“MIME type mismatch”。
为什么浏览器报“MIME type mismatch”却没加载CSS
根本原因不是CSS文件写错了，而是服务器返回的 Content-Type 响应头不是 text/css。现代浏览器（尤其是Chrome 90+）会严格校验这个值，哪怕文件内容完全正确，只要Header不对，就直接拒绝解析并报错：Refused to apply style from 'xxx.css' because its MIME type ('text/plain') is not a supported stylesheet MIME type.
常见触发场景：静态文件托管在Nginx/Apache但未显式配置类型；用Python http.server 或 Node.js 原生 http 模块起服务时没设Header；CDN回源未透传或覆盖了Content-Type。
Nginx中强制设置CSS的Content-Type
Nginx默认靠文件扩展名匹配MIME类型，但有时mime.types缺失、被覆盖，或你用了非标准后缀（比如.styl），就得手动加固。
- 在
server或location块里加：add_header Content-Type text/css;—— 不推荐，它会覆盖所有响应头，可能破坏JSON等其他资源 - 正确做法是用
types指令确保扩展名映射准确：types { text/css css; }，并确认include mime.types;已启用 - 若只针对某类路径，用
location匹配后加default_type text/css;（注意：这是兜底类型，仅当无更精确匹配时生效）
Apache里修复.css的MIME类型
Apache通常依赖mime_module，但容易被.htaccess里的AddType覆盖或遗漏。
立即学习“前端免费学习笔记（深入）”；
- 检查是否启用了模块：
a2enmod mime（Debian/Ubuntu）或确认LoadModule mime_module modules/mod_mime.so在配置中 - 在
httpd.conf或虚拟主机配置中添加：AddType text/css .css - 如果用了
ForceType或SetHandler，它们会强行覆盖MIME类型，需排查并移除无关指令 - 重启服务后，用
curl -I https://yoursite.com/style.css验证响应头中是否含Content-Type: text/css
开发服务器（如Vite、Webpack Dev Server）为何不报错
因为它们默认把.css响应头设为text/css，且不校验请求来源。但上线后换成Nginx/Apache就暴露问题——这说明本地能跑通≠线上安全。
真正要盯住的是部署环节的配置一致性：
- 不要假设“生产环境和开发一样”，必须对齐
Content-Type行为 - 用
curl -I或浏览器Network面板看真实响应头，别只信文件后缀或本地预览 - 如果用了CDN，确认其“MIME类型自动识别”开关是否打开；某些CDN（如Cloudflare）会缓存错误的Header，需清缓存+检查回源响应
最隐蔽的坑是：服务器返回了text/css，但前面多了一个BOM或空格，导致实际Header变成 text/css（带前导空格），浏览器仍判定为非法——这种空白字符肉眼几乎不可见，只能靠curl -v原始响应体确认。
