能，但只适合快速验证或轻量子应用；它通过重写选择器添加唯一前缀实现作用域限制，无法隔离body/html全局样式、第三方库注入样式及@keyframes动画，且易导致antd等UI库样式失效。
qiankun 的 experimentalStyleIsolation 能直接用吗？
能，但只适合快速验证或轻量子应用。它通过自动重写所有 CSS 选择器（如 .btn → div[data-qiankun="app"] .btn）实现作用域限制，无需改构建配置。
常见错误现象：body 或 html 上的全局字体、滚动条样式失效；第三方库（如 antd 的 @font-face）注入的样式被隔离出界；@keyframes 动画名未被重写导致动画不触发。
实操建议：
前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。
- 关闭该选项后手动用
ScopedCSS类处理关键样式节点，更可控 - 若子应用用了
normalize.css或reset.css，必须提前剥离或转为内联<style>并手动加前缀 - 不要依赖它隔离第三方 UI 库的全局样式，它们往往绕过 DOM 插入逻辑
CSS Modules 在微前端里为什么经常“漏隔离”？
因为默认行为不保证类名唯一性，且容易被构建链路绕过。它本质是编译时哈希化类名 + JS 映射，但隔离生效前提是：所有样式都走 css-loader 的 modules 流程，且不能混用普通 .css 引入。
立即学习“前端免费学习笔记（深入）”；
关键参数差异：css-loader 的 modules.mode 必须设为 'local'；若设为 'pure'，会跳过作用域处理，类名原样输出。
常见错误现象：子应用引入了 bootstrap/dist/css/bootstrap.css（非 module），结果 .btn 直接污染全局；Vue 单文件组件中 <style scoped> 和 <style module> 混用，后者未生效。
实操建议：
- 把 UI 库样式全部转为
import 'xxx/dist/css/xxx.module.css'形式 - Webpack 配置中用
test: /\.module\.(css|scss|sass)$/精确匹配，避免漏掉非标准后缀 - 配合
postcss-modules自动生成类型定义，防止 JS 中引用错类名
Shadow DOM 是不是“一劳永逸”的样式隔离方案？
不是。它确实能阻断大部分样式继承和污染，但代价是破坏 Web 平台原生能力边界，尤其在微前端整应用挂载场景下问题集中。
典型兼容性影响：Chrome/Firefox 支持良好，Safari 对 :host-context() 和跨 Shadow Root 的 CSS Custom Properties 继承支持不稳定；IE 完全不支持。
常见错误现象：document.querySelector('.app-header') 查不到 Shadow 内元素；子应用内 @font-face 加载失败；getComputedStyle(el) 返回空值；父应用设置的 font-size: 14px 无法透传到 Shadow 内。
实操建议：
- 只对独立 UI 组件（如
<my-button>）启用 Shadow DOM，别封装整个子应用 - 子应用初始化前，手动克隆主应用已加载的字体、变量定义并注入到 Shadow Root 的
<style>中 - 慎用
::slotted和:host-context()，它们会主动穿透隔离边界
命名空间前缀（BEM/CSS-in-JS）需要团队强约定吗？
需要，而且是最容易被低估的落地成本。BEM 类名（如 .app1-card__header）或 CSS-in-JS 的动态 scope（如 styled.div`&& { color: red; }`）本身不提供运行时保护，完全依赖开发自觉。
性能影响较小，但维护成本高：一旦某位成员漏加前缀，或第三方库未提供 prefix 配置项（如某些旧版 Element UI），污染立刻发生；主题切换时需同步更新所有前缀变量，易遗漏。
实操建议：
- 用 ESLint 插件（如
eslint-plugin-css-modules）校验 import 路径是否含module关键字 - 在 CI 阶段用 Puppeteer 抓取子应用 HTML，正则扫描是否存在无前缀的
class="btn"类名 - 优先选用支持运行时注入的方案（如 Styled Components 的
StyleSheetManager），而非纯构建时前缀
真正难的不是选哪个方案，而是让不同技术栈、不同交付节奏的子应用，在同一套规则下长期稳定共存。多数团队卡在「约定执行」和「工具兜底」的平衡点上——自动化的样式重写容易出边界 case，纯人工约定又难以持续。最务实的做法，是主应用统一提供基础样式契约（CSS Custom Properties），子应用只负责消费和局部覆盖，隔离层收口到框架侧，而不是摊派给每个业务线。
