https页面中任何http资源引用都会被浏览器必然阻止，主动资源如script、iframe、fetch等直接拦截，控制台报错明确提示被拦资源，network面板过滤mixed可定位全部问题。
HTTPS 页面里只要出现任何 http:// 资源引用，浏览器就会触发混合内容（Mixed Content）拦截——不是“可能冲突”，而是“必然阻止”，尤其对 <script></script>、<iframe></iframe>、fetch() 这类主动资源。
怎么一眼定位哪个资源被拦了
打开浏览器开发者工具 → 切到 Console 标签页，直接看红色报错。典型格式是：
Mixed Content: The page at 'https://example.com/page.html' was loaded over HTTPS, but requested an insecure script 'http://cdn.example.net/lib.js'. This request has been blocked; the content must be served over HTTPS.
错误里明确写了：谁（page.html）在 HTTPS 下，试图加载谁（http://cdn.example.net/lib.js）。再切到 Network 标签页，用过滤器选 Mixed，或 Ctrl+Shift+F 搜 http://，所有未升级的请求一目了然。
哪些标签和 API 会直接被拦截
不是所有 http:// 都一样待遇。浏览器按风险等级区别处理：
-
<script src="http://..."></script>、<link href="http://...">、<iframe src="http://..."></iframe>：主动混合内容，Chrome/Firefox/Edge 默认硬性拦截，不加载、不执行、无回退 -
<img src="http://...?x-oss-process=image/resize,p_40">、<video src="http://..."></video>：被动混合内容，部分浏览器仍加载但砍掉地址栏小锁，iOS Safari 可能直接不显示 -
fetch("http://api.example.com")、XMLHttpRequest：同主动资源，请求发不出去，控制台报net::ERR_INSECURE_RESPONSE或直接TypeError: Failed to fetch
协议相对 URL（//）还管用吗
写成 src="//cdn.example.com/script.js" 曾经是常用技巧，但它有隐藏陷阱：
- 如果目标域名根本没开 HTTPS（比如老旧内网服务、已停用的 CDN），页面走 HTTPS 时，
//会自动拼成https://，结果 404 或证书错误 - 某些企业防火墙或代理会重写
//请求，导致协议降级 - 2026 年主流 CDN 和公共服务基本全支持 HTTPS，显式写
https://更可靠，还能提前暴露证书问题
后端接口也得 HTTPS 吗
必须。哪怕你只用 fetch() 调自家 API，只要前端页面是 HTTPS，而 fetch("http://api.example.com") 就会被拦截。常见误区：
- 认为“同域名就没事”：错。协议不同（
https://site.com→http://api.site.com）仍算跨协议，触发混合内容 - 以为 Nginx 反向代理能绕过：不能。浏览器看到的是响应头里的
Location或最终请求地址，不是你配置的 proxy_pass - 开发环境用
http://localhost:3000测试正常？上线前务必换成https://api.example.com，否则生产环境必挂
最易被忽略的一点：第三方 SDK（比如统计、客服、埋点）的初始化代码里常藏死链接，它们可能自己拼接 http://，且不暴露在你写的 HTML 里——得查 Network 中实际发出的请求，不能只扫源码。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
