iframe是微前端的运行时集成载体，核心价值在于天然隔离子应用；但需JS动态管控生命周期、postMessage跨域通信、URL同步及错误降级等能力才能构成完整方案。

iframe 不是“做”微前端的工具，而是微前端的一种**运行时集成载体**。它本身不提供路由、通信、生命周期等能力，但能天然隔离子应用——这是它被选为微前端方案的核心原因。

为什么直接写 <iframe src="..."> 不能算完整微前端

纯静态 iframe 标签只能加载页面，但微前端需要：主应用控制子应用切换、响应 URL 变化、透传用户登录态、跨域通信、错误降级。这些都得靠 JS 主动管理。

• 浏览器刷新后，iframe 的 src 不会自动同步当前 URL（比如你点导航跳到 /order，但 iframe 还在 /home）
• 点击浏览器「后退」按钮，主应用路由变了，但 iframe 内容卡死不动
• 子应用如果跨域，iframe.contentDocument 直接报 SecurityError，连 DOM 都读不到
• 主应用无法感知子应用是否加载失败，容易白屏无提示

loadMicroApp() 动态创建 iframe 的关键点

硬编码 <iframe src="xxx"> 适合演示，生产必须用 JS 动态创建并管控生命周期。

• 每次切换前先 iframe.remove() 或清空容器，避免残留旧实例和内存泄漏
• 设置 iframe.sandbox 属性（如 "allow-scripts allow-same-origin"）来显式放开能力，而不是依赖默认行为
• 监听 iframe.onload 仅表示 HTML 加载完成，不等于 JS 执行完毕；需配合子应用主动发 postMessage({ type: 'MOUNTED' }) 才算真正就绪
• 给每个 iframe 设置唯一 name 属性，方便后续通过 window.frames['xxx'] 定向通信

跨域通信必须用 postMessage()，且要校验来源

主应用和子应用不在同一域名下时，postMessage 是唯一可行的通信方式，但极易因疏忽导致安全漏洞或消息丢失。

Article To Html

文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。

下载

• 发送方必须指定目标 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 内部跳转不会触发主应用监听

真实项目里最容易被忽略的，是子应用加载失败后的兜底策略——比如网络超时、CORS 拒绝、JS 报错未挂载。这时候不能只留一个空白 iframe，而应该显示错误状态、提供重试按钮，并记录上报。