MicroFrontends为何易出现CSS冲突

Micro Frontends 中 CSS 冲突源于全局样式作用域失控，而 Shadow DOM 虽能提供严格的样式与 DOM 隔离，却绝非“开箱即用”的银弹——它仅保护挂载在 shadowRoot 内部的元素，一旦子应用绕过隔离层操作 document.body、依赖第三方库默认挂载行为、忽略 @font-face/@keyframes 手动注入，或框架未适配 shadowRoot 挂载上下文，样式泄漏便不可避免；更严峻的是，strictStyleIsolation 等配置若缺乏主子应用协同（如预创建 closed shadowRoot、重写 mount 逻辑、事件与 API 重定向），反而会引发查询失效、调试困难、兼容性陷阱等现实问题，真正稳健的实践往往需融合 Shadow DOM 封装关键组件、运行时选择器重写、前缀命名约束与设计系统令牌治理的组合策略。

Shadow DOM 不能自动解决微前端的 CSS 冲突，它只对挂载在其内部的元素生效；一旦子应用绕过 shadowRoot 直接操作 document.body 或动态插入节点到主文档，样式立刻泄漏。

Shadow DOM 的隔离边界非常明确

它不是“给整个子应用套个壳”就万事大吉。隔离只发生在 shadowRoot 节点树内部：子应用渲染的所有 DOM 必须作为其子节点存在，且所有样式规则必须注入到该 shadowRoot 中（比如通过 shadowRoot.appendChild(styleEl) 或 CSSStyleSheet.insertRule）。否则，document.querySelector('.btn') 找到的仍是全局节点，样式自然不生效。

常见错误现象：

• 子应用用 document.body.appendChild(div) 弹出一个全局提示框，这个 div 完全不受 Shadow DOM 控制
• 第三方 UI 库（如 antd、element-plus）默认挂载到 document.body，需显式配置 getContainer 指向 shadowRoot
• @font-face 和 @keyframes 不会自动继承进 Shadow DOM，必须手动克隆并注入

qiankun 的 strictStyleIsolation: true 并不等于“开箱即用”

这个配置会强制创建 shadowRoot 并把子应用根节点塞进去，但代价是：子应用内所有 DOM 查询和事件监听必须切换上下文。

你不能再写：

document.querySelector('.header')

而必须写：

shadowRoot.querySelector('.header')

更麻烦的是，框架层往往不默认支持。例如：

• Vue 3 的 createApp 默认 mount 到 document，需传入 { root: shadowRoot } 或重写 app.mount()
• React 的 ReactDOM.createRoot() 必须指向 shadowRoot，而非 document.getElementById('root')
• window.addEventListener('resize') 在 closed 模式下根本收不到事件，因为 window 不在 shadow 上下文中

为什么 styledIsolation: true 经常看起来“没效果”

因为它的行为依赖容器是否已有 shadowRoot。如果主应用只是给子应用预留了一个普通