问题在于代理工具篡改了css响应头的content-type，导致浏览器拒绝应用样式；需检查并确保响应头中存在content-type: text/css，否则即使内容正确也会被丢弃。
当你在用Charles或Fiddler调试网页时，发现CSS文件请求被拦截但样式始终不生效，浏览器控制台报“Refused to apply style”，而Network面板里该CSS请求状态码是200、内容可查看——问题不在文件路径或语法，而在代理工具悄悄改写了响应头。
确认是否被代理篡改Content-Type
打开浏览器DevTools → Network → 找到被拦截的.css请求 → 点击进入 → 切换到Response Headers标签页。
重点检查是否存在【Content-Type: text/css】这一行。若缺失，或显示为text/plain、application/octet-stream、甚至空值，说明代理工具未透传或覆盖了原始响应头。
这一步必须做，因为浏览器只认text/css才加载样式；其他类型哪怕内容完全正确，也会直接丢弃。
Charles中关闭自动重写MIME类型
Charles默认会对某些静态资源强制设置Content-Type，尤其当后端未返回时，它会按文件扩展名补一个——但这个补全逻辑不可靠，常把.css错设为text/plain。
操作路径：Charles → Proxy → SSL Proxying Settings → 取消勾选“Enable SSL Proxying”（先临时关掉，避免干扰判断）→ 再进入Proxy → Options → HTTP Proxy → 取消勾选“Automatically set Content-Type based on file extension”。
【此选项一旦开启，Charles会无视服务器真实响应头，强行按后缀重写Content-Type】，关掉后它将原样转发服务端返回的头。
Fiddler中禁用响应头自动注入
方法一：Rules → Customize Rules → 在OnBeforeResponse函数内查找类似oSession.oResponse.headers.SetHeader("Content-Type", "text/plain")的代码，整行删除或注释掉。
方法二（更稳妥）：启动Fiddler → Tools → Options → HTTPS → 取消勾选“Decrypt HTTPS traffic” → 然后回到Connections选项卡 → 取消勾选“Use Windows authentication for upstream proxies”。
这两项关闭后，Fiddler不再尝试解密或重写HTTPS响应，对CSS这类静态资源能保持原始Content-Type不变。
验证代理是否真在中间动了手脚
第一步：在Charles/Fiddler中右键目标CSS请求 → Save Response → 保存为style.css文件。
第二步：用文本编辑器打开该文件 → 检查开头是否有BOM或不可见字符（尤其是UTF-8 with BOM格式容易触发IE/旧版Chrome拒绝解析）。
第三步：用curl直连原始URL（绕过代理）：curl -I http://your-domain.com/style.css → 对比返回的Content-Type是否与代理中看到的一致。
如果curl返回text/css，而代理里是text/plain，那就坐实了代理工具在篡改响应头。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
