Nginx 返回非 text/css 的 Content-Type 会导致 CSS 不被解析；需在 http 块中显式 include mime.types，禁用 default_type，验证响应头并排除 CDN 与缓存干扰。
text/css，CSS 就不会被浏览器解析——哪怕文件 200 可访问，样式也必然失效。
确认 mime.types 已加载且生效
mime.types 文件里定义了 .css → text/css 的映射，但它默认不启用。必须在 http { } 块中显式包含：
- 检查配置中是否有
include mime.types;；没有就加上 - 路径通常为
/etc/nginx/mime.types（Linux）或/usr/local/etc/nginx/mime.types（macOS），可用find / -name mime.types 2>/dev/null确认实际位置 - 切勿在
location块内重复include mime.types——它只应在http层作用，重复可能干扰继承 - 改完必须运行
nginx -t测试，再nginx -s reload生效
避免 location 块意外覆盖 MIME 类型
常见错误是写了 location /static/ { } 却没声明类型逻辑，导致 mime.types 失效：
- 禁用
default_type application/octet-stream;——它会强制把所有未匹配资源当成二进制流，CSS 直接被丢弃 - 若用正则匹配如
location ~ \.css$，需加types { };或显式add_header Content-Type text/css;（仅调试用） - 推荐用前缀匹配 +
root/alias，并确保该location内没写default_type或types指令干扰继承
验证响应头是否真实正确
别只看 Network 面板状态码是 200，重点盯 Content-Type 响应头：
- 命令行验证：
curl -I https://yoursite.com/style.css | grep "Content-Type"，期望输出Content-Type: text/css - 若返回
text/plain、application/octet-stream或为空，说明mime.types没生效，或被某处default_type覆盖 - CDN（如 Cloudflare）可能覆盖原始响应头——先关 CDN 或直连服务器 IP 测试
- 浏览器缓存可能返回旧响应头，加
curl -H "Cache-Control: no-cache"或清空 DevTools 缓存重试
检查 alias/root 路径是否严丝合缝
alias 不是拼接，是替换；root 是拼接。写错一级路径，CSS 就 404，根本走不到 MIME 类型判断那步：
立即学习“前端免费学习笔记（深入）”；
- 前端引用
/css/app.css，配置location /css/ { alias /app/static/css/; }→ 正确映射到/app/static/css/app.css - 若误写成
location /static/css/ { alias /app/static/css/; }，请求/css/app.css就不命中，直接 fallback 到其他规则或 404 - 容器部署时，宿主机路径与容器内路径不一致也会导致 404，务必用
ls -l /app/static/css/app.css实际验证文件存在且 Nginx 有读取权限
mime.types 却忘了 nginx -s reload；验证时用了 CDN 缓存；或者 alias 路径末尾多了一个斜杠。这些细节一漏，就变成“明明配对了却没效果”。 
