iframe的src写http地址时，浏览器绝不会自动升级为https；upgrade-insecure-requests对iframe src无效，唯一可靠方式是手动将src="http://example.com"改为src="https://example.com"。
iframe src 写 HTTP 地址时，浏览器不会自动升级为 HTTPS
直接把 src="http://example.com" 改成 src="https://example.com" 是唯一可靠方式。浏览器从不自动把 iframe 的 HTTP 协议“升格”为 HTTPS——upgrade-insecure-requests 这个 CSP 指令对 iframe 的 src 完全无效，它只管页面内加载的图片、脚本、样式等资源，不管导航类行为（如 iframe、a 标签跳转、location.href）。
本地开发时 iframe 加载失败，大概率是 file:// 协议惹的祸
双击打开 index.html 会触发 file:// 协议，此时任何 src 值（哪怕写的是 https://）都可能被拦截或静默失败，控制台报 net::ERR_FAILED 或 Blocked a frame with origin "null"。
- 必须起本地服务器：用
http-server、live-server或 VS Code 的 Live Server 插件，确保地址形如http://localhost:5500/index.html - 同域嵌入（如
src="/dashboard.html"）可走相对路径；跨域嵌入（如src="https://maps.google.com"）需目标页响应头含Access-Control-Allow-Origin，且不能被其自身sandbox策略阻断 - 绝对禁止
src=""或src="about:blank"后再 JS 赋值——Chrome 会提前触发加载并报net::ERR_UNKNOWN_URL_SCHEME
HTTPS 页面里 iframe 加载 HTTP 地址，会被当成混合内容拦截
主页面是 https://，但 src="http://thirdparty.com"，现代浏览器（Chrome/Firefox/Edge）会直接阻止加载，并在控制台打印类似 Blocked loading mixed active content 的错误。这不是配置问题，是强制安全策略。
- 解决路径只有两条：把目标页升级到 HTTPS，或通过反向代理（如 Nginx）把
http://thirdparty.com代理成同域 HTTPS 接口（注意目标页是否允许被 iframe 嵌入） - 别指望
<meta http-equiv="Content-Security-Policy">或<meta http-equiv="Strict-Transport-Security">能起作用——前者对src无效，后者根本不能写在 HTML 里 - 如果目标页是你自己维护的，确认它返回了
X-Frame-Options: SAMEORIGIN或Content-Security-Policy: frame-ancestors 'self'，否则即使协议匹配也会被拒
sandbox 属性会影响 iframe 是否能发起 HTTPS 请求
sandbox 默认禁用所有能力，包括脚本执行、表单提交、弹窗、以及发起网络请求（含 fetch、XMLHttpRequest 和 iframe 自身的初始 src 加载）。如果你加了 sandbox 却没显式放开，iframe 可能连 HTTPS 地址都加载不了。
- 最小可用组合是：
sandbox="allow-scripts allow-same-origin"（注意：两者需同时存在才允许同源脚本运行） - 若需跨域加载 HTTPS 内容，必须加
allow-scripts，但allow-same-origin不能和跨域一起用（否则沙箱失效），此时只能依赖目标页的 CORS 和frame-ancestors配置 -
sandbox的权限列表优先级高于 CSP 头，即服务端发了frame-ancestors，但 HTML 里写了sandbox且没给allow-scripts，照样白屏
src 协议由你写的字符串决定，而浏览器是否放行，取决于主页面协议、目标页面协议、服务端响应头、以及 sandbox 的显式授权——四者缺一不可。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
