真正可靠的样式隔离需运行时沙箱+样式作用域控制；Shadow DOM虽可隔离但兼容性差、适配成本高；主流采用编译时加前缀+运行时动态重写选择器并劫持DOM操作；qiankun strictStyleIsolation存在绕过劫持、CSS-in-JS、@import嵌套及全局reset干扰等漏点；根本解法是主应用scoped重置+子应用禁用全局样式。
微前端里子应用样式污染主应用怎么办
直接上结论：纯 CSS 命名空间（比如加前缀）只能防手抖，不能防意外；真正可靠的隔离得靠运行时沙箱 + 样式作用域控制，但浏览器原生不提供全局样式沙箱，所以得自己补一层逻辑。
用 createShadowRoot 或 attachShadow 能完全隔离样式吗
能，但代价高、兼容性差、且和多数微前端框架不兼容。Shadow DOM 确实天然隔离样式，但：
– Vue/React 的渲染逻辑默认不进 Shadow Root（需手动适配，比如 Vue 的 shadowRoot 选项或 React 的 createRoot + attachShadow）
– 子应用如果用了 document.querySelector、getComputedStyle 或第三方 UI 库（如 Element Plus、Ant Design），大概率直接报错或失效
– iframe 更彻底，但通信成本高、SEO 友好性归零、无法共享状态
实际项目中怎么低成本做样式隔离
主流方案是「编译时 + 运行时」双保险，重点在运行时劫持和重写：
- 子应用构建时自动添加唯一前缀（如
app-a-），通过 PostCSS 插件postcss-prefix-selector或 Webpack 的css-loader的modules.auto+localIdentName实现 - 加载子应用时，动态重写其
<style></style>标签内容：遍历所有 CSS 规则，给选择器加上容器 class（如.micro-app-container[data-app="app-a"]），再插入 - 拦截子应用对
document.head.appendChild的调用，把新注入的<style></style>重定向到带前缀的 scope 容器内 - 禁用子应用执行
document.styleSheets的读取（部分沙箱如qiankun的 strictStyleIsolation 模式会清空该属性）
qiankun 的 strictStyleIsolation 为什么有时还是漏样式
因为这个模式只处理动态插入的 <style></style> 和 <link rel="stylesheet">，对以下情况无能为力：
立即学习“前端免费学习笔记（深入）”；
- 子应用在 JS 中拼接字符串后直接
document.write或innerHTML注入样式（绕过劫持） - CSS-in-JS 库（如 styled-components、emotion）生成的 style 标签没走标准 DOM 插入流程
- 子应用用了
@import在 CSS 文件里嵌套加载，而父应用未递归解析并重写 - 全局 reset.css / normalize.css 被主应用提前载入，子应用样式仍可能被它影响（比如
button { margin: 0 }）
真正稳的做法是：主应用统一提供基础样式重置（scoped 到自身容器），子应用禁用任何全局 reset，并约定只使用 CSS Modules 或 CSS-in-JS 的局部模式。
样式隔离不是“加个开关就完事”，关键在子应用是否真正放弃对全局样式的幻想——这点比技术方案更难推动。
