bem 的“命名空间”靠唯一 block 名（如 myapp-header）和作用域隔离实现，非语法机制；冲突主因是 block 名重复或未加业务前缀，解决需前缀统一、禁用非bem选择器、确保 modifier 成对声明。
为什么 BEM 的命名空间能避免组件样式冲突
BEM（Block Element Modifier）本身不提供命名空间机制，所谓“命名空间”其实是靠 block 名称的唯一性和作用域隔离来实现的。跨项目迁移时，真正起作用的是：每个组件以独立、语义化且带业务前缀的 block 开头（比如 myapp-header、checkout-button），而非泛用 header 或 button。一旦 block 名重复，样式就会叠加或覆盖——这不是 BEM 的缺陷，而是没守好命名边界。
常见错误现象：.header__title 在两个项目里都存在，但字体、间距规则不同，合并后后者直接覆盖前者；或者某个项目全局重置了 .button，结果把 BEM 组件里的 .card__button 也意外影响了。
- 所有
block名必须带明确项目/产品/业务前缀，如salesforce-form、legacy-modal - 禁止在外部 CSS 文件中用通配符或低优先级选择器（如
[class*="button"]）去“捕获” BEM 类名 - 若需复用组件，应同步迁移其完整 CSS 块（含所有
block__element--modifier变体），不能只搬block主类
如何为已有组件添加安全的命名空间前缀
直接改 HTML class 是最稳妥的方式，但工程量大；CSS 层面加前缀（如 .ns-salesforce .salesforce-form）反而会破坏 BEM 的扁平结构和可预测性，还可能因嵌套层级引发权重问题。推荐用构建时自动注入前缀。
使用 PostCSS 插件 postcss-bem 或自定义 postcss-prefixwrap，对整个组件 CSS 文件做包裹：
/* 输入：原始组件 CSS */
.myform { display: block; }
.myform__input { padding: 8px; }
<p>/<em> 构建后（加前缀 ns-abc）</em>/
.ns-abc .myform { display: block; }
.ns-abc .myform__input { padding: 8px; }
</p>
- 前缀必须加在最外层容器元素上（如
<div class="ns-abc">），不能靠 CSS 选择器模拟作用域<li>避免用 <code>:where()或:is()包裹 BEM 类——它们会重置优先级，导致 modifier 覆盖失效 - Webpack 中可通过
css-loader的modules.localIdentName配合 BEM 模式生成带哈希的局部作用域，但会丢失语义，不推荐用于跨项目共享组件 -
block内部用了非 BEM 的子选择器，如.card__body p——一旦目标项目有全局p样式，就失控 - Modifier 写成布尔型却未声明默认态，如只写了
.button--primary，没写.button基础样式，迁移后按钮直接无样式 - Element 命名含通用词且未限定上下文，如
.dialog__close看似合理，但若另一项目也有.dialog块，__close就可能被误复用或冲突 - 每个组件的
block名在组织内全局唯一（建议注册到内部组件目录） - 所有样式必须通过
block或其子孙 BEM 类触发，禁用标签/属性/ID 选择器 - Modifier 必须成对出现：
block--mod和block基础类共存，不可拆分发布
跨项目迁移时哪些 BEM 模式最容易踩坑
不是所有 BEM 写法都适合迁移。以下三类在合并后极易出问题：
解决办法：迁移前用工具扫描组件 CSS，检查是否包含标签名、属性选择器、未声明的基础类、以及跨 block 的 __ 命名重复（可用正则 /__\w+/g 提取所有 element 名比对）。
要不要用 CSS-in-JS 或 Shadow DOM 替代 BEM 命名空间
可以，但没必要为了迁移而切换技术栈。BEM 本身是命名约定，不是运行时隔离方案。CSS-in-JS（如 Emotion）通过哈希类名天然隔离，Shadow DOM 提供样式封闭，它们确实更“安全”，但代价是：构建复杂度上升、调试困难、SEO 友好性下降、且无法与纯 CSS 项目直连复用。
真正关键的不是换方案，而是守住三条线：
跨项目迁移最难的从来不是语法，而是确认那个 user-card 到底是用户中心的卡片，还是 CRM 里的联系人卡片——名字一样，语义不同，这才是命名空间失效的起点。
