直接改用https://协议是唯一可靠解法，因//协议相对路径存在HTTPS端点缺失、参数敏感等风险，而主动混合内容如<link>会在TCP连接前被浏览器策略性拦截，导致blocked:mixed-content。
直接改用 https:// 协议，别碰协议相对 URL（//），这是唯一可靠解法。
为什么浏览器连请求都不发就报 Mixed Content
<link rel="stylesheet"> 属于主动混合内容（Active Mixed Content），浏览器在建立 TCP 连接前就直接丢弃 HTTP 请求。Network 面板里对应条目 Status 明确显示 blocked:mixed-content，不是超时、也不是 404 —— 是策略性拦截。
它能篡改渲染树、影响 getComputedStyle()、触发 FOUC，甚至劫持后续资源加载。所谓“只是样式”是典型误判。
- 本地开发用
https://localhost:3000加载页面，却引用线上http://xxx.com/style.css，同样触发拦截 - 第三方 CSS 文件内部的
@import url("http://...")或background: url("http://...")也会被拦，且出现在 Network 子请求中
怎么快速定位所有被拦的 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="http://...">- 后端模板拼接的链接，如
echo '<link href="http://' . $host . '/css/app.css>' - CSS 文件里的
@import url("http://")和url("http://") - JS 动态创建的
link元素，如document.createElement('link')+el.href = 'http://...'
为什么 //cdn.example.com/style.css 不安全
协议相对 URL 看似省事，但风险陡增：很多老旧内网静态服务、测试 CDN、第三方字体服务（如某些自建 font server）根本不提供 HTTPS 端点，一用就 404 或跳转失败。
还有更隐蔽的问题：// 对 query 参数敏感，比如 //cdn.example.com/style.css?v=1.2.3，若目标服务 HTTPS 证书异常或不支持该参数，照样失败；而显式写 https:// 可提前暴露问题，便于排查。
- 直接把
http://fonts.googleapis.com/改成https://fonts.googleapis.com/，99% 能通（截至 2026 年中） - CDN 如
jsdelivr、unpkg、cdnjs全部支持 HTTPS，无需犹豫 - 自动化替换推荐：
npx replace-in-file 'http://' 'https://' ./src/**/*.{html,css,js} --isRegex
修复后仍报错？注意这三处隐藏位置
常见漏网之鱼：
- HTML 中
<meta name="viewport">后面紧跟的<link>，容易被忽略 - Webpack/Vite 构建产物中硬编码的
publicPath，比如output.publicPath = 'http://cdn.example.com/' - 服务端渲染模板（如 EJS、Twig）里用变量拼出的
href，需检查变量来源是否带协议
最麻烦的是第三方 SDK 自动注入的 <link>，得查其文档是否支持强制 HTTPS 配置项，否则只能用 CSP 的 upgrade-insecure-requests 临时兜底 —— 但这不解决根本，且部分旧浏览器不支持。
