https页面中iframe的src为http://时，浏览器会在发起请求前静默拦截，不生成network条目，仅在console报mixed content错误；修复必须显式改为https://，csp upgrade-insecure-requests对iframe无效。
HTTPS 页面里 iframe 的 src 写成 http://，浏览器根本不会发请求，直接静默拦截——这不是 bug，是强制安全策略，改协议是唯一解法。
为什么 Chrome 控制台报 Mixed Content 却看不到 Network 请求
因为浏览器在发起网络请求前就拦截了。主动混合内容（比如 iframe、script、fetch()）属于“被内核级拒绝”，Network 面板里连条目都不会生成。你看到的错误信息，是渲染引擎在解析 HTML 时直接抛出的，不是加载失败后的反馈。
- 打开 DevTools → Network 标签页，点 Filter 输入
Mixed Content，通常为空——这正说明请求压根没出去 - 真正有效的排查路径是：Console 报错 → 锁定哪一行
iframe src="http://..."→ 改成https://... - 注意：即使目标域名支持 HTTPS，也不能依赖自动升级；必须显式写全协议，否则部分旧环境（如 Cordova、某些 WebView）会 fallback 失败
用 upgrade-insecure-requests CSP meta 标签行不行
它只对页面内资源（如 img、link、script）生效，iframe src 不受其影响。W3C 规范明确将 iframe 排除在该指令作用范围外。
- 写
<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">对 iframe 无效 - 这个 meta 只能帮你在不改 HTML 的前提下“抢救”一部分图片或 CSS，但不能绕过 iframe 的混合内容拦截
- 如果你控制不了 iframe 的 src 字符串（比如由后端模板拼接），那就必须让后端输出 https 协议，前端 JS 动态修正也仅限同域且未跨源场景
本地开发和生产环境协议不一致怎么办
本地用 http://localhost:8080，生产用 https://example.com，硬编码协议会导致一处改、处处崩。最稳的方式是：所有 src 属性都显式声明协议，且与当前页面 location.protocol 保持一致。
- 避免
//example.com/page.html这种协议相对地址——它在 HTTP 页面走 HTTP，在 HTTPS 页面走 HTTPS，但 Safari 14 之前、某些 Electron 或 Cordova 环境下解析不可靠 - 推荐 JS 动态赋值：
iframe.src = location.protocol + '//example.com/page.html' - 如果 iframe 是服务端渲染的，确保模板引擎读取
req.protocol（Express）或request.scheme（Django）来拼协议
检查 X-Frame-Options 和 CSP frame-ancestors 前先确认协议是否正确
90% 的 iframe 空白问题根源是混合内容，不是服务端头配置。等你把 http:// 全换成 https:// 后，再查目标页是否返回 X-Frame-Options: DENY 或 Content-Security-Policy: frame-ancestors 'none'——这两者你无法绕过，只能联系目标服务提供方调整响应头。
容易被忽略的是：即使协议正确、目标页允许嵌入，若父页面自己加了 Content-Security-Policy: frame-src 'self'，而 iframe 指向的是第三方域名，也会被拒绝。这时候要检查父页响应头里的 frame-src 或 default-src 是否包含目标域名。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
