HTML组件化本身不自带通信机制，实际依赖customElements、postMessage、CustomEvent和observedAttributes四种原生能力；其中observedAttributes实现props透传需JSON序列化，CustomEvent适用于同域轻量广播，iframe因路由不同步、样式穿透及安全限制被主流框架弃用，localStorage因竞态与安全问题不推荐。
HTML 组件化本身不自带通信机制，所谓“通信”其实是靠浏览器原生能力组合实现的——customElements、postMessage、CustomEvent 和属性监听这四类手段最常用，选错路径会卡在路由不同步、样式穿透或内存泄漏上。
用 observedAttributes 实现父传子 props
这是最接近“HTML 原生通信”的方式：主应用通过 HTML 属性传参，子组件用 observedAttributes 响应变更。
- 属性值只能是字符串，复杂数据必须
JSON.stringify()后传入，子组件用JSON.parse(this.getAttribute('config'))解析 - 修改属性必须调用
el.setAttribute('config', ...)，直接赋值el.config = obj不触发attributeChangedCallback -
observedAttributes只监听 attribute 变更，不响应对象内部字段变化（比如{a: 1}改成{a: 2}，若字符串序列化结果没变，就不会触发） - 若子应用是 React/Vue 构建的，需用适配器包装（如
@lit/react），否则无法响应原生属性变更
用 CustomEvent + window.dispatchEvent 做同域广播
适合主题切换、登录态同步这类轻量全局通知，但不能用于细粒度调用（比如 A 子应用按钮点击触发 B 子应用表单校验）。
- 事件名必须加前缀防冲突，例如
mf:theme-change，避免和第三方库事件撞名 - 传参只能是可序列化对象，
function、DOM node、Promise会丢失 - 监听必须在子应用挂载后注册，卸载前调用
removeEventListener，漏掉就内存泄漏 - 跨域场景下无效，
postMessage才是唯一合法通道
为什么别用 <iframe> 直接通信
主流微前端框架（如 qiankun、Module Federation）已弃用 iframe 模式，不是技术做不到，而是它带来的问题比解决的多。
立即学习“前端免费学习笔记（深入）”；
- 同域下读取
iframe.contentWindow在开启 COOP/COEP 头后大概率抛SecurityError -
iframe内子应用的history.pushState不同步到主应用，路由失控 - 样式穿透需依赖
shadow DOM+adoptedStyleSheets，IE11 和旧版 Safari 不支持 - SEO 友好性差，搜索引擎难以索引 iframe 内容
localStorage 不是通信方案
它看起来像“共享存储”，实际是竞态高发区，且缺乏事件可见性与安全边界。
- 多个子应用同时写同一 key，无原子操作，容易覆盖或丢失状态
- 变更不会自动触发事件，监听方得轮询或靠 MutationObserver 间接捕获，延迟高
- 敏感数据存 localStorage 易被 XSS 窃取，不符合最小权限原则
真正难的不是怎么传数据，而是谁负责清理、谁保证顺序、谁承担序列化失败的后果——这些契约必须在设计阶段就约定清楚，而不是等上线后靠 console.error 补救。
