iframe必须使用https协议且配置严格csp与origin校验。需禁用混合内容、显式设置sandbox、服务端配frame-src/frame-ancestors、postmessage前监听load并全匹配event.origin。
iframe加载前必须检查src协议是否为HTTPS
现代浏览器会直接拦截HTTP资源嵌入，报Mixed Content错误。这不是兼容性问题，而是强制策略。
常见错误是本地开发用http://localhost:3000能跑通，上线后 iframe 白屏且控制台静默失败。
- 生产环境
src必须写死https://trusted.example.com/path.html，不能用*或相对路径 - 若第三方只提供HTTP服务，必须自己搭反向代理（如Nginx），把
https://yourdomain.com/proxy/xxx转给http://thirdparty.com -
allow="clipboard-read"等属性对协议降级无效，别指望靠它绕过
sandbox属性必须显式启用，且避免allow-scripts与allow-same-origin共存
不加sandbox的iframe等于给外部页面开了任意代码执行权限——它能弹窗、提交表单、跳转top.location，甚至尝试DOM注入。
allow-scripts allow-same-origin同时存在时，Chrome 126+ 会直接忽略整个sandbox属性，子页仍被当跨域处理，window.parent为null，但开发者误以为“已打通”，实际权限没放开。
- 最小可行配置：仅开
allow-scripts（需JS交互）或allow-downloads（需下载PDF等） - 真要读写
localStorage或同源fetch，必须确认src是你完全可控的同源地址（协议、域名、端口三者一致） - 静态内容（如PDF、图片）直接去掉
allow-scripts，靠服务器响应头控制行为更可靠
父页发postMessage前必须监听load事件，子页收消息必须校验event.origin
直接在iframe标签后调用iframe.contentWindow.postMessage()大概率失败——此时contentWindow还是null，不是延迟问题，是DOM根本没就绪。
子页若只校验event.data.type === 'init'或用event.origin.includes('example.com')，攻击者可伪造origin字段绕过。
- 父页正确写法：
frame.addEventListener('load', () => { frame.contentWindow.postMessage(...); }); - 子页必须用全匹配：
if (event.origin !== 'https://parent.example.com') return;，不能用includes或startsWith -
load事件对404/500也会触发，需配合error事件做兜底
服务端必须配CSP frame-src和frame-ancestors，不能只靠HTML属性
HTML里写了<iframe src="https://a.com"></iframe>，但父页响应头有Content-Security-Policy: frame-src 'self'，浏览器照样拒绝加载，控制台报Refused to frame 'https://a.com/'。
X-Frame-Options已被frame-ancestors取代，后者支持多源、'self'和none，优先级更高。
- Express/Django等框架常默认注入CSP，但
frame-src需单独补全，否则白写src - 测试可用
<meta http-equiv="Content-Security-Policy" content="frame-src https://trusted.com;">模拟，但它无法覆盖服务端头 - 如果允许嵌套，
frame-ancestors应精确到域名，避免写*或宽泛通配
event.origin全匹配——前者让iframe根本加载不了，后者让通信通道形同虚设。这两处不卡死，其他防护都可能被绕过。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
