iframe加载失败主因是协议不匹配或沙箱权限缺失，需确保src用https、配置sandbox属性、检查csp响应头，并轮询readystate判断真实就绪状态。
现代浏览器默认拦截 HTTP 资源嵌入 HTTPS 页面，iframe 加载失败十有八九是协议不匹配或沙箱权限缺失，不是代码写错了。
src 必须用 HTTPS，HTTP 会被当成 Mixed Content 拦截
Chrome、Firefox 等主流浏览器在 HTTPS 页面里加载 http://example.com 的 iframe，会直接拒绝并报错：Blocked loading mixed active content。这不是 bug，是强制策略。
- 源站只提供 HTTP？必须自己搭反向代理（如 Nginx），把
http://target.com代理成https://yourdomain.com/proxy/target，再让src指向代理地址 - 开发阶段可用
localhost或127.0.0.1绕过部分限制，但上线前必须真实 HTTPS -
allow="clipboard-read"这类属性完全不解决协议问题，别被误导
sandbox 属性不是可选，而是默认锁死所有能力
没加 sandbox 的 iframe，一旦嵌入不可信页面，它就能执行 JS、读取父页面 DOM、弹窗、提交表单——相当于给你页面开了个远程 shell。
- 默认至少写
sandbox="allow-scripts"，只开脚本执行权 - 需要跨域通信才加
allow-same-origin，但注意：allow-scripts和allow-same-origin不能共存于同一sandbox值中（除非 iframe 与父页同源），否则整个 sandbox 属性被浏览器忽略 - 想让 iframe 里调用父页函数？必须用
window.postMessage()，parent.xxx()在跨域下直接报错
Content-Security-Policy 头比 HTML 属性优先级更高
即使你写了 <iframe src="https://a.com"></iframe>，如果服务器响应头里有 Content-Security-Policy: frame-src 'self'，浏览器照样拒绝加载，并报错：Refused to frame 'https://a.com/' because it violates the following Content Security Policy directive。
- 检查后端框架（如 Express、Django）是否默认注入 CSP，常漏掉
frame-src配置 - 开发时可用
<meta http-equiv="Content-Security-Policy" content="frame-src https://trusted.com;">模拟测试，但它无法覆盖服务端下发的头 - 线上环境必须确认响应头中的
frame-src或default-src明确放行目标域名
onload/onerror 不可靠，得轮询 readyState
iframe.onload 只在资源“加载完成”时触发，但不保证内容可交互；onerror 对跨域失败、CSP 拒绝等场景根本不会触发。
- 判断 iframe 是否真正就绪，应定时轮询
iframe.contentDocument?.readyState === 'complete' - 务必设超时（比如 10 秒），避免无限等待
- 首次加载失败后，手动设置
iframe.src = iframe.src触发重试，比监听事件更可控
真正麻烦的从来不是怎么写 <iframe src=""></iframe>，而是搞清谁在拦、为什么拦、拦住了怎么查——协议、沙箱、CSP、加载状态，四层关卡缺一不可。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
