qiankun的styledIsolation必须开但不能依赖它实现完全隔离：它仅控制<style>标签挂载位置（shadowRoot或head），不改写选择器、不处理@import/<link>/CSS-in-JS，且Vite子应用需额外用postcss-prefix-selector加前缀，UI库须重编译或显式传入namespace。
qiankun 的 styledIsolation 到底要不要开？
开了不一定隔离，不开肯定污染——它只管样式挂载位置，不管选择器内容。
常见错误现象：styledIsolation: true 后，子应用的 @import 样式、<link rel="stylesheet">、CSS-in-JS 动态插入的 <style> 全部逃逸到全局 <head>；控制台看不到报错，但 Ant Design 按钮颜色被主应用覆盖了。
-
styledIsolation: true：仅对子应用内<style>标签生效（且需浏览器支持CSSStyleSheet+adoptedStyleSheets），旧版 Safari 会直接降级为无隔离 -
styledIsolation: { strictStyleIsolation: true }：强制创建shadowRoot，但子应用所有document.querySelector、getComputedStyle必须改用shadowRoot.querySelector，否则查不到元素 - 不配置或设为
false：所有样式进主文档<head>，靠加载顺序和 CSS 权重硬扛，极易漏——这不是配置问题，是机制决定的
Vite / Webpack 子应用如何避免 CSS 路径 404？
子应用构建后 CSS 文件路径写死为 /css/app.abc123.css，但实际部署在 /subapp-order/css/app.abc123.css，结果就是样式完全不加载。
必须让构建产物中的静态资源路径与主应用注册时的 entry 一致。
立即学习“前端免费学习笔记（深入）”；
前端设计优化skill
下载
前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。
- Vite：配置
build.base，区分环境：window.__POWERED_BY_QIANKUN__ ? '/subapp-order/' : '/' - Webpack：设置
publicPath为运行时动态值，例如process.env.NODE_ENV === 'production' ? '/subapp-order/' : '/' - 构建后务必检查产物中所有
<link href>的路径，确认与主应用registerMicroApps里传入的entry完全匹配（协议、域名、路径均需一致）
Element Plus / Bootstrap 这类 UI 库怎么加命名空间？
光靠 import 或 link 引入，等于主动把污染源塞进全局——浏览器不管你是微前端，CSS 就是全局生效的。
关键不是“能不能隔离”，而是“必须主动重编译或显式传参”。
- Element Plus：初始化时传入
{ namespace: 'ep' }，让类名变成ep-button；同步修改 SCSS 变量，在src/styles/element/index.scss中写@forward 'element-plus/theme-chalk/src/mixins/config.scss' with ($namespace: 'ep');，并确保该文件被全局注入（Vite 配置css.preprocessorOptions.scss.additionalData，Webpack 配置sass-loader.additionalData） - Bootstrap：不能只给
<body>加 class，得用 Sass 重编译源码：.bootstrap-iso { @import "bootstrap/scss/bootstrap"; }；JS 组件如Modal必须显式传入带前缀的选择器：new Modal(document.querySelector('.bootstrap-iso .modal')) - Vue2 + ElementUI 和 Vue3 + ElementPlus 共存时，
.el-input__inner这类共享前缀类名会被后加载的样式直接覆盖，输入框边框消失——沙箱拦不住，因为规则已写进 DOM
Shadow DOM 整应用封装为什么总出问题？
能隔离，但代价是破坏原生行为——不是技术不行，是 Web 平台规范本身就不支持整页 Shadow 封装。
常见失效场景：document.querySelector 查不到元素、@font-face 字体加载失败、CSS 变量 无法继承、@keyframes 动画名全局冲突、<slot> 内容仍受外部样式影响。
- 不要用
shadowRoot.innerHTML = htmlString直接注入 HTML，这会让内联<style>和<script>逃逸至全局；必须用DOMParser解析后，将<style>转为CSSStyleSheet实例，再通过shadowRoot.adoptedStyleSheets = [sheet]注入 -
mode: 'open'不适合生产——外部 JS 可通过element.shadowRoot直接篡改子应用 DOM 和样式表；应始终用{ mode: 'closed' }，此时shadowRoot返回null，但调试时需配合自定义钩子（如暴露__debugShadow） - 第三方库若依赖
shadowRoot（如某些 Web Component polyfill），需提前 patch，否则初始化失败
@keyframes 名称这些，根本不受 class 前缀或 Shadow DOM 影响。它们是真正的全局注册项，连 adoptedStyleSheets 都管不了——只能靠 CI 阶段 AST 扫描拦截，禁止子应用直接操作 document.documentElement 和 document.head。 
