Chrome直接丢弃HTTP CSS请求，因<link>属主动混合内容，浏览器在发起前就拦截；需用DevTools Network面板筛选mixed定位，并将所有http://显式替换为https://。
必须把所有 http:// 显式替换成 https://，不能用 // 协议相对 URL，也不能依赖 CSP 自动升级。
为什么浏览器连请求都不发就报 blocked:mixed-content
<link rel="stylesheet"> 属于主动型混合内容，浏览器在 TCP 连接建立前就直接丢弃 HTTP 请求。你不会看到 404 或超时，Network 面板里 Status 列清清楚楚写着 blocked:mixed-content。这不是加载失败，是策略性拦截——因为 CSS 能篡改渲染树、影响 getComputedStyle()、触发 FOUC，甚至劫持后续资源。
常见被拦位置包括：
<link href="http://fonts.googleapis.com/css?...">- CSS 文件内部的
@import url("http://...") - 后端模板拼接的链接，如
echo '<link href="http://' . $host . '/css/app.css>' - JS 动态创建的
link元素：el.href = 'http://cdn.example.com/style.css'
怎么快速定位所有被拦的 HTTP CSS
别靠肉眼扫 HTML。打开 Chrome DevTools → Network 标签页 → 刷新页面 → 在 Filter 输入框输入 mixed，所有被拦请求立刻高亮。点击任一项，看 Initiator 列，就能反查到是哪行 <link> 或 JS 插入导致的。
立即学习“前端免费学习笔记（深入）”；
更准的做法是全局搜索：
- 按
Ctrl+Shift+F（Windows/Linux）或Cmd+Option+F（macOS）搜http:// - 重点检查：
<link rel="stylesheet" href="...">、CSS 文件里的@import和url("http://")、JS 中动态设置的href - 本地开发用
https://localhost:3000加载页面，却引用线上http://xxx.com/style.css，同样触发拦截
为什么 //cdn.example.com/style.css 不安全
协议相对 URL 看似省事，但风险陡增：
- 很多老旧内网静态服务、测试 CDN、第三方字体服务（如某些自建 font server）根本不提供 HTTPS 端点，一用就
404 -
//对 query 参数敏感，比如//cdn.example.com/style.css?v=1.2.3，若目标服务 HTTPS 证书异常或不支持该参数，照样失败 - 某些代理或企业防火墙会拦截
//请求并降级为 HTTP，导致静默失败 - 它无法提前暴露问题，而显式写
https://可在第一时间发现证书异常或重定向问题
CSS 内部的 @import 和 url() 容易被忽略
这些引用不会出现在 HTML 里，却一样触发 blocked:mixed-content，且在 Network 面板中显示为子请求。必须进 CSS 文件逐行检查：
- 查找所有
@import url("http://、@import "http:// - 查找所有
url("http://、background: url("http://、src: url("http:// - 字体声明如
@font-face { src: url("http://...") }同样要改
真正难处理的是那些由构建工具注入、或从 CMS 导出的 CSS——它们可能藏在打包产物里，得结合 sourcemap 或原始源文件一起查。最稳妥的做法不是“找完再改”，而是把 CI 流程加上 grep -r "http://" src/ | grep -i "\.css\|\.html" 类似的检查步骤，避免漏掉。
