浏览器拒绝执行CSS的根本原因是服务器未返回Content-Type: text/css响应头，而非type属性或文件后缀错误；file://协议无HTTP头导致本地双击必失效，必须用本地服务器并验证Network面板中CSS请求的Content-Type值。
浏览器拒绝执行CSS，不是因为“没看到样式”，而是它压根不信任你传来的数据——Content-Type不对，就当它不是CSS。
浏览器只认Content-Type响应头，不看type属性或文件后缀
HTML里写<link rel="stylesheet" href="style.css" type="text/css">，这个type属性只是文档提示，Chrome、Firefox、Edge 90+ 全部忽略它。真正起作用的，是服务器在HTTP响应头里返回的Content-Type: text/css。如果返回的是text/plain、text/html、application/octet-stream，甚至空值，浏览器会直接丢弃该资源，并在控制台报错：Refused to apply style from 'xxx.css' because its MIME type is 'text/html'。
更关键的是：一旦服务器设置了X-Content-Type-Options: nosniff（现代CDN和生产环境默认启用），浏览器连“嗅探补救”都不做，容错率为零。
为什么file://协议下必现此问题
双击HTML文件用Chrome打开，走的是file://协议——它没有HTTP响应头，浏览器无法获取Content-Type，只能依赖操作系统注册表或文件关联。而Windows默认可能把.css映射为text/plain，Mac/Linux则完全不可靠。
立即学习“前端免费学习笔记（深入）”；
在 Linux 上通过 Chrome 挂载/VNC 自动发布小红书长笔记。Agent 撰写标题和正文后执行 xhs_publish.sh --publish --submit，触发小红书发布。
- 这不是你代码的问题，是协议本身不支持MIME协商
- IE9+、Chrome 60+、Firefox 都已明确拒绝加载
file://下的非text/cssCSS - 临时验证：用
python -m http.server 8000或http-server起服务，再访问http://localhost:8000/index.html
常见服务器配置中Content-Type失效的三种典型场景
即使你写了AddType text/css .css或add_header Content-Type text/css，仍可能失败：
- Nginx里漏了
include mime.types;，或/etc/nginx/mime.types里没这行：text/css css; - Apache中
AddType被ForceType或SetHandler覆盖，且未检查模块是否启用（a2enmod mime） - Express中
express.static()没放在路由中间件之前，导致请求被其他中间件拦截，Content-Type根本没机会设
最可靠验证方式：打开开发者工具 → Network → 找到那个CSS请求 → 点开 → Headers → 拉到底看Response Headers里的Content-Type值。路径对、文件存在、标签标准，全都没用——只要这里不是text/css，样式就永远不会生效。
容易被忽略的“假404”陷阱：返回HTML却当成CSS解析
当你看到MIME type is 'text/html'，第一反应不该是改服务器配置，而是立刻复制href地址（比如http://localhost:3000/css/main.css）粘贴进新标签页回车。如果看到的是404页面、登录跳转页、Vue/React兜底路由页，说明路径错了，或者静态资源没托管到该路径下。
Linux服务器还额外注意大小写：Style.css ≠ style.css；构建产物若输出到dist/css/，但HTML里写的是href="css/style.css"，而当前页面在子目录下，相对路径就会断掉。
