微前端中CSS冲突是默认行为而非bug，需通过Shadow DOM或CSS Modules等方案隔离，但各有局限，统一构建配置和约束第三方库挂载点才是关键。
因为不隔离，.card、.button、body 这类常见选择器会直接跨应用打架，一个子应用改个 margin，另一个就白屏或错位——这不是 bug，是必然结果。
微前端里 CSS 冲突不是“可能”，而是“默认行为”
CSS 天然全局生效，浏览器不关心你用没用微前端。主应用加载了 reset.css，子应用又带了一份 normalize.css；主应用写了 #app .title { font-size: 18px }，子应用的 .title 就会被强制继承——优先级、层叠顺序、加载时机全在暗处起作用，调试时根本看不出谁覆盖了谁。
- 子应用 A 的
.modal被主应用的.modal { z-index: 10 }压住，弹窗点不了 - 子应用 B 动态插入的
style标签，把主应用的html { font-size: 62.5% }给重置了 - 第三方 UI 库（如 Ant Design）挂载到
document.body的浮层，样式被外部规则穿透
Shadow DOM 是最彻底的隔离，但别盲目开
strictStyleIsolation: true 看起来是银弹，实际会暴露三类硬伤：
PigX UI 前端开发
下载
PigX UI Pro 前端开发指南 - Vue 3 + TypeScript + Element Plus。当用户提到 PigX UI、PigX 前端、lgb-mgui 项目、Vue 3 企业级后台开发、Element Plus 后台开发时使用此技能。
- IE11、旧版 Edge 完全不支持，降级逻辑得自己兜底
- 子应用里用
ReactDOM.createPortal或el.append()挂到body的节点，会脱离 Shadow DOM，样式瞬间失效 - 主应用和子应用之间传参、事件通信必须走
CustomEvent+shadowRoot.host，写法比普通 DOM 复杂一倍
CSS Modules 是多数项目的务实选择
它不依赖运行时环境，靠构建阶段重命名实现隔离，但要注意两个易忽略点：
立即学习“前端免费学习笔记（深入）”；
-
:global(.el-icon)这种写法会绕过模块化，如果子应用用了第三方图标库的 class，得手动加 global 声明，否则图标不显示 - Webpack 的
css-loader配置里modules.auto默认只对.module.css生效，写成Button.css就不会处理 - 动态生成的 className（比如
className={`btn ${type}`}）中type如果没走styles[type]映射，照样会泄露到全局
真正难的从来不是选哪种方案，而是所有子应用是否统一构建配置、是否禁用 !important、是否约束第三方库的挂载点——这些细节没人帮你检查，出问题时也不会报错，只会默默让页面变丑。
