HTML本身不提供微前端通信能力，实际依赖customElements、postMessage和事件系统；iframe因隔离性、路由同步、样式穿透及安全限制被主流框架弃用；CustomEvent适用于同域轻量广播但有参数序列化与内存泄漏风险；Web Component通过observedAttributes透传props需JSON序列化；localStorage因竞态、事件不可见及安全问题不推荐；通信本质是生命周期与契约约定。
HTML 本身不提供微前端通信能力，customElements、postMessage 和事件系统才是实际载体——纯 HTML 标签（如 <div> 或 <slot>）无法跨子应用传递状态或触发逻辑。
为什么不能靠 <iframe> 直接通信
<iframe> 隔离性强，但跨域时 postMessage 是唯一合法通道；同域下虽可访问 iframe.contentWindow，但需手动绑定事件监听、处理序列化、避免内存泄漏。多数微前端框架（如 qiankun、Module Federation）主动禁用 <iframe> 模式，因其无法共享路由、样式隔离困难、SEO 友好性差。
- 同域下直接读取
iframe.contentWindow容易触发SecurityError（尤其开启COOP/COEP头后） -
<iframe>内子应用的history.pushState不会同步到主应用，路由失控 - 样式穿透需靠
shadow DOM+adoptedStyleSheets，但 IE11 和旧版 Safari 不支持
CustomEvent + window.dispatchEvent 的适用边界
适用于同域、无沙箱、轻量级通信（如主题切换、用户登录态广播），但不适用于细粒度组件间调用（比如子应用 A 的按钮点击触发子应用 B 的表单校验）。
- 事件名必须全局唯一，建议加前缀如
mf:theme-change，避免冲突 - 传参只能是可序列化对象，函数、DOM 节点、Promise 会丢失
- 监听需在子应用挂载后注册，卸载前移除——漏掉
removeEventListener会导致内存泄漏 - 主应用发事件，子应用收；反过来也行，但需确保目标子应用已初始化
如何让 props 从主应用透传到 Web Component 子应用
Web Component 是目前最贴近“HTML 实现通信”的可行路径：主应用通过属性（props）注入数据，子应用用 static get observedAttributes() 响应变更。
立即学习“前端免费学习笔记（深入）”；
- 属性值只能是字符串，复杂数据需 JSON.stringify 后传入，子组件解析：
JSON.parse(this.getAttribute('config')) - 修改属性必须用
el.setAttribute('config', JSON.stringify(obj))，直接赋值el.config = obj不触发attributeChangedCallback - 若子应用是 React/Vue 构建，需包装一层
customElement适配器（如@lit/react或vue-custom-element），否则无法响应原生属性变化 - 注意：
observedAttributes不监听对象内部属性变更，只响应 attribute 的 set/remove
为什么 localStorage / sessionStorage 不推荐用于通信
它看似简单，但实际引入竞态和延迟问题：存储写入后，其他子应用需轮询或监听 storage 事件，而该事件在当前页面不触发（仅在其他同源 tab 触发），导致主应用无法感知自己刚存的数据。
-
storage事件监听不到本页发起的变更，调试时极易误判“没生效” - 多个子应用并发写同一 key，无原子操作，可能覆盖
- 敏感信息（如 token）不应明文存于
localStorage，违反安全规范 - 若子应用使用 service worker 缓存，
storage更可能不同步
真正关键的不是“用什么 HTML 标签”，而是谁控制生命周期、谁持有通信契约。微前端通信的本质是约定——无论是事件名、属性名还是消息格式，一旦子应用未按约定监听或解析，HTML 层面再怎么写都只是空壳。
