shadow dom 不是微前端样式隔离的通用推荐方案，而是仅适用于轻量级 web components 的强隔离手段；整应用挂载会导致 document 查找失效、第三方库挂载异常、字体动画丢失、css 变量继承中断等问题，且存在兼容性差、调试困难、性能开销大等工程缺陷。
Shadow DOM 不是“推荐用于微前端样式隔离”的通用方案，而是特定场景下可选的强隔离手段——但它在多数真实微前端项目中反而要慎用，甚至应主动规避。
Shadow DOM 在微前端里根本不能直接套用整应用
常见错误是把整个子应用挂进 shadowRoot。这会导致：
-
document.querySelector('body')返回null，所有依赖全局 DOM 查找的逻辑崩掉 - 第三方库（如 antd、element-plus）默认挂载到
document.body，结果节点跑出 shadowRoot，样式立刻失效 -
@font-face和@keyframes无法跨 boundary 加载，字体图标/动画全丢 -
css custom properties继承中断，:host外部传入的主题色读不到
它只对 Web Components 风格的轻量组件真正有效
如果你的子应用本质是一个独立 UI 卡片、配置面板或嵌入式工具（非完整 SPA），才适合用 Shadow DOM：
- 必须用
customElements.define()注册，而非new Vue()或ReactDOM.render() - 所有 DOM 操作限定在
shadowRoot内，包括事件监听和动态插入节点 - 要用
mode: 'closed'才能防 JS 窥探，但代价是 Chrome DevTools 无法 inspect 内部结构 - 需手动克隆
@import、字体、变量定义等资源到shadowRoot.innerHTML中的<style></style>
qiankun/micro-app 等框架里的 “Shadow DOM 模式” 是妥协实现
它们并非原生 Shadow DOM，而是运行时劫持 CSSStyleSheet.insertRule + 动态加前缀，再配合 attachShadow 挂载容器。关键限制：
- 仍需子应用禁用
document.write、innerHTML = '<style>'</style>等直写方式 - 伪类选择器（
:hover）、属性选择器（[data-id]）、全局选择器（body）无法加前缀，照样泄漏 - Safari 对
slot内容的 CSS 变量继承有 bug，IE 完全不支持 - 频繁切换子应用时，
shadowRoot创建/销毁开销比 class 切换高 3–5 倍
真正容易被忽略的点：Shadow DOM 解决的是「组件级封装」问题，而微前端要解决的是「运行时应用共存」问题——前者靠浏览器原生机制，后者靠工程化兜底。硬套会把简单问题复杂化，尤其当子应用来自不同技术栈且无法改造时。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
