qiankun 的 experimentalStyleIsolation 仅给样式加 data-qiankun 前缀而不改 BEM 类名，需确保 block 名与子应用 name 一致，禁用 scoped/CSS Modules 避免冲突，修饰符须由 JS 显式控制。
qiankun 的 experimentalStyleIsolation 会重写 BEM 类名，但不破坏语义
开启 experimentalStyleIsolation: true 后，qiankun 会为子应用所有样式规则自动添加前缀，例如将 .user-card__submit--disabled 改写为 [data-qiankun="user-center"] .user-card__submit--disabled。这个过程只加选择器前缀，不修改类名本身。
这意味着你写的 BEM 类名依然完整保留，user-card__submit 还是那个块+元素+修饰符结构，DevTools 里能直接搜索、JS 里能准确 querySelector、stylelint 也能继续校验。它不是“帮你生成新类名”，而是“把已有类名锁进容器作用域”。
常见错误现象：
- 误以为开了沙箱就不用写 BEM —— 实际上没 BEM，
[data-qiankun] .btn仍可能被其他子应用的.btn覆盖（权重相同，后加载胜出） - 在子应用里手动加冗余前缀，如
[data-qiankun="user-center"] .user-card__submit—— qiankun 会再套一层，变成双重前缀，导致样式不生效
BEM 的 block 名必须与子应用 ID 对齐，否则沙箱前缀失效
qiankun 的 experimentalStyleIsolation 依赖子应用注册时传入的 name 字段生成 data-qiankun 属性值。BEM 的 block 名若不与此一致，就会出现「命名空间错位」：CSS 规则被注入到容器内，但 JS 查找或调试时用的是另一套逻辑。
立即学习“前端免费学习笔记（深入）”；
比如子应用注册为：
registerMicroApps([{
name: 'user-center',
entry: '//localhost:8001',
container: '#subapp-viewport'
}])
那么它的 BEM block 名就该是 user-center，对应类名如 user-center__header、user-center__form--compact。不能简写成 user 或泛义词 profile。
前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。
否则会出现：
- CSS 规则被加了
[data-qiankun="user-center"]前缀，但你写的类名是profile__header，实际匹配的是[data-qiankun="user-center"] .profile__header—— 完全不命中 - 团队协作时，有人按 block 名查组件目录，结果去翻
/components/profile/，而真实路径是/components/user-center/
禁止在 BEM 类名中混用沙箱机制和构建时 Scoped 处理
有人想“双重保险”，一边开 experimentalStyleIsolation，一边在 Vue 里用 <style scoped> 或 Webpack 配 css-loader?modules。这会导致三重问题：
- CSS 文件里写的是
.user-center__btn，但构建后变成.user-center__btn_abc123，qiankun 再加前缀变成[data-qiankun="user-center"] .user-center__btn_abc123—— 类名彻底脱离 BEM 可读性，调试时无法反推源码 - JS 中通过
el.classList.add('user-center__btn--loading')动态操作，但实际 DOM 上的类名是哈希化的，操作无效 - 第三方库（如 antd）的样式无法被 scoped，反而因沙箱前缀权重升高，意外覆盖主应用原有样式
正确做法是二选一：
– 纯运行时隔离：关掉 CSS Modules / scoped，靠 BEM + experimentalStyleIsolation 组合；
– 构建时隔离：关掉 qiankun 沙箱 CSS，用 CSS Modules + BEM 命名双约束（此时 block 名仍需与子应用 ID 一致，用于目录和 JS 关联）。
修饰符状态必须由 JS 显式控制，不能依赖沙箱自动注入
qiankun 不会识别或处理 BEM 修饰符，--disabled、--dark 这些只是普通字符串。沙箱只管“这个样式能不能生效”，不管“这个状态该不该加”。
所以 user-center__submit--disabled 是否存在，完全取决于你的 JS 是否调用 el.classList.toggle('user-center__submit--disabled')。如果只靠 CSS 规则写了 .user-center__submit--disabled { opacity: 0.5; }，但 JS 没加这个类，那它就是个死样式。
容易踩的坑：
- 在 HTML 模板里静态写死
class="user-center__submit user-center__submit--disabled"，上线后发现禁用态无法动态切换 - 把状态逻辑藏在父级修饰符里，比如只加
user-center--disabled，再靠.user-center--disabled .user-center__submit控制子元素 —— 这违反 BEM “每个视觉单元独立响应状态”原则，也绕过了沙箱对子元素的选择器限制（前缀只加在最外层） - 用 CSS-in-JS 库（如 emotion）动态生成带前缀的类名，结果和 qiankun 的前缀机制冲突，样式重复或丢失
真正难的不是写对类名，而是让每个 --modifier 都有明确、可追踪、可测试的 JS 触发点。沙箱只划清地盘，BEM 只定义名字，谁来决定什么时候亮起那个名字——得靠人写清楚。
