在微前端架构中，BEM 类名必须使用静态字符串，而不能依赖 CSS-in-JS 动态生成。这样做的核心价值在于保证 SSR 输出一致、避免 hydration mismatch，同时满足子应用独立构建和命名空间隔离的需求。

微前端中BEM类名为什么不能靠CSS-in-JS动态生成

微前端中的子应用通常需要分别构建，再按需异步加载；而在 SSR 或首屏直出的场景下，JavaScript 往往还没有完成执行。问题正出在这里：像 useId()、css 模板字符串，或 styled-components 这类方案生成的哈希类名（例如 sc-a1b2c3），在服务端渲染阶段往往无法稳定产出。最终就会出现典型的 hydration mismatch——客户端与服务端生成的类名不一致，React 或 Vue 往往会直接放弃现有 DOM 并重新 render，轻则页面闪烁，重则导致交互异常甚至失效。

而 BEM 使用的是纯静态字符串：user-profile__a vatar--xs 在 HTML 模板、SSR 输出和客户端 JS 中始终保持一致，不需要任何运行时计算。

• 所有 BEM 类名都应直接写死在模板或常量对象中，禁止通过随机 ID、时间戳、Math.random() 等方式动态拼接
• 如果微前端主应用采用后端模板（如 PHP/Ja va Thymeleaf）直接输出 HTML，那么 BEM 类名就是前后端都能稳定识别的样式契约
• 子应用迭代升级时，只要继续遵循 block__element--modifier 结构，主应用中的 CSS 文件通常无需修改也能持续生效

子应用之间样式隔离靠BEM前缀，不是靠!important或scoped

微前端项目中一个常见误区，是给子应用大量添加 !important，或者依赖