Custom Element 不能直接当微前端用，因其仅提供 DOM 注册与实例化，缺乏挂载上下文、沙箱作用域和资源卸载机制，需手动补全 Shadow DOM 封装、资源加载控制和生命周期桥接三能力层。
原生 Custom Element（自定义元素）确实能实现微前端的“即插即用”，但前提是严格规避跨框架生命周期冲突、样式隔离缺失和资源重复加载这三类问题——它不是开箱即用，而是开箱即踩坑。
为什么 customElements.define() 不能直接当微前端用
浏览器原生的自定义元素只负责 DOM 注册与实例化，不提供挂载上下文、沙箱作用域或资源卸载机制。常见错误现象包括：
- 子应用多次
define()同一名字报Failed to execute 'define' on 'CustomElementRegistry': the name "xxx" has already been used - 子应用内使用
React.render()或Vue.createApp()后，父应用切换路由时子应用组件未销毁，内存泄漏 - 子应用 CSS 全局污染父应用，比如
.btn { color: red }直接覆盖全站按钮颜色
根本原因：Custom Element 只是 Web Components 规范中的一环，缺少 Shadow DOM（默认未启用）、模块作用域和运行时卸载钩子。
必须手动补全的三个能力层
要让自定义元素真正承载微前端职责，需在 connectedCallback() 和 disconnectedCallback() 中注入对应逻辑：
立即学习“前端免费学习笔记（深入）”；
-
资源加载控制：用
import('./app-remote.js')动态导入子应用入口，避免全局 script 标签导致的重复执行；加载前检查window.__MICRO_APP_LOADED__防止多实例并发加载 -
Shadow DOM 封装：在
constructor()中调用this.attachShadow({ mode: 'closed' })，再将子应用根节点 append 到 shadowRoot —— 否则样式和事件完全暴露 -
生命周期桥接：在
connectedCallback()中触发子应用mount()，在disconnectedCallback()中显式调用其unmount()；若子应用是 React，需保存root实例并调用root.unmount()
attributeChangedCallback() 是通信唯一安全出口
父应用向子应用传参不能靠 props 或 data-* 属性自动映射，因为 Custom Element 不解析属性值类型，所有 attribute 都是字符串。典型误用：
<micro-react-app config='{"theme":"dark"}' />
// 子元素中 this.config 是字符串，不是对象
正确做法是监听 attributeChangedCallback(attrName, oldVal, newVal)，对关键属性做 JSON.parse 或类型转换：
- 只监听明确声明的
observedAttributes，如['config', 'env']，避免无谓触发 - 对
config这类复杂结构属性，要求父应用传 base64 编码字符串，子应用解码后JSON.parse()，规避单引号/双引号引发的 HTML 解析失败 - 禁止在回调中直接调用子应用渲染逻辑，应 emit 自定义事件如
this.dispatchEvent(new CustomEvent('config-change', { detail }));，由子应用内部订阅
构建时必须拆离公共依赖，否则 runtime 冲突不可避免
如果父应用用了 React 18，子应用也打包了 React 18，两个 react-dom 实例会互相干扰，出现 Invalid hook call 或状态不同步。解决方案只有两个：
- 子应用构建时把
react、react-dom、vue等设为external，由父应用统一提供，通过window.React访问（需父应用提前挂载） - 若无法共享，子应用必须用
createRoot+hydrateRoot模式，并确保其container是 Shadow DOM 内的独立节点，与父应用 DOM 完全隔离
最易被忽略的是 CSS-in-JS 库（如 Emotion、Styled Components）——它们依赖全局 context，即使用了 Shadow DOM，主题 Provider 仍可能穿透。此时只能放弃动态主题，改用 CSS 变量 + :host 选择器手动注入。
