iframe是微前端的运行时集成载体，核心价值在于天然隔离子应用；但需js动态管控生命周期、postmessage跨域通信、url同步及错误降级等能力才能构成完整方案。
iframe 不是“做”微前端的工具，而是微前端的一种**运行时集成载体**。它本身不提供路由、通信、生命周期等能力，但能天然隔离子应用——这是它被选为微前端方案的核心原因。
为什么直接写 <iframe src="..."></iframe> 不能算完整微前端
纯静态 iframe 标签只能加载页面，但微前端需要：主应用控制子应用切换、响应 URL 变化、透传用户登录态、跨域通信、错误降级。这些都得靠 JS 主动管理。
- 浏览器刷新后，
iframe的src不会自动同步当前 URL（比如你点导航跳到/order，但 iframe 还在/home） - 点击浏览器「后退」按钮，主应用路由变了，但
iframe内容卡死不动 - 子应用如果跨域，
iframe.contentDocument直接报SecurityError，连 DOM 都读不到 - 主应用无法感知子应用是否加载失败，容易白屏无提示
loadMicroApp() 动态创建 iframe 的关键点
硬编码 <iframe src="xxx"></iframe> 适合演示，生产必须用 JS 动态创建并管控生命周期。
- 每次切换前先
iframe.remove()或清空容器，避免残留旧实例和内存泄漏 - 设置
iframe.sandbox属性（如"allow-scripts allow-same-origin"）来显式放开能力，而不是依赖默认行为 - 监听
iframe.onload仅表示 HTML 加载完成，不等于 JS 执行完毕；需配合子应用主动发postMessage({ type: 'MOUNTED' })才算真正就绪 - 给每个
iframe设置唯一name属性，方便后续通过window.frames['xxx']定向通信
跨域通信必须用 postMessage()，且要校验来源
主应用和子应用不在同一域名下时，postMessage 是唯一可行的通信方式，但极易因疏忽导致安全漏洞或消息丢失。
- 发送方必须指定目标
origin（如iframe.contentWindow.postMessage(data, 'https://sub.example.com')），不能写'*' - 接收方必须检查
event.origin是否在白名单内，否则直接return - 子应用初始化完成后，应主动发一次
{ type: 'READY', payload: { version: '1.2.0' } }，让主应用确认环境可用 - 避免高频发送消息，可节流或合并数据；
postMessage是异步且无序的，不要依赖执行顺序
URL 同步和前进/后退支持不是浏览器自带的
浏览器的 history API 默认只管理主窗口 URL，iframe 完全无感。要实现「点后退，iframe 也切回上一个子应用」，必须手动桥接。
- 主应用用
history.pushState()改变 URL 时，同时更新iframe.src并触发子应用重载 - 监听
window.onpopstate，根据event.state中记录的子应用标识重新加载对应iframe - 子应用自身也要监听自己的
hash或search变化（如location.hash = '#/detail/123'），但不能操作主应用 history - 若子应用是单页应用（SPA），需禁用它的 history 模式，改用
hash路由，否则 iframe 内部跳转不会触发主应用监听
iframe，而应该显示错误状态、提供重试按钮，并记录上报。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
