BEM与OOCSS不可混用，因二者设计理念冲突：OOCSS强调跨上下文复用原子类（如.btn），BEM强调块内语义绑定（如.button__icon）；混用导致样式来源模糊、权重竞争、调试困难及CSS体积膨胀。
BEM 与 OOCSS 不是互补关系，强行“结合”反而会稀释各自的设计意图；OOCSS 强调抽象复用（如 .btn、.media），BEM 强调语义化层级（如 .header__logo--large），二者在组件粒度、命名逻辑和职责边界上存在根本冲突。
为什么 .btn--primary 和 .button__icon 不能混用
OOCSS 的 .btn 是一个独立、可复用的外观原子，它的变体（.btn--primary）只改变视觉状态，不依赖上下文；而 BEM 的 .button__icon 明确绑定在 .button 这个块内，语义上不可脱离父块存在。一旦把两者写在一起（比如 <button class="btn button__icon">），CSS 就面临样式来源模糊、权重竞争、调试困难的问题。
- 浏览器开发者工具里看到
.button__icon覆盖了.btn的padding，但你不确定是 BEM 规则强，还是 OOCSS 基础类加了!important -
.btn在项目其他地方被复用为纯文本链接，但.button__icon的 margin-left 会意外影响它 - 构建工具无法静态分析出哪些
--modifier实际只用于某个__element，导致 CSS 体积膨胀
真正在工程中“共存”的常见形态
团队不会同时用两套命名体系写同一个组件，而是按场景分层使用：OOCSS 管控基础 UI 原子（表单控件、卡片容器、栅格系统），BEM 管控业务模块（.product-list、.checkout-step）。关键在于隔离作用域。
- 基础层用 OOCSS：定义
.form-control、.card、.grid-row，禁止出现__或-- - 业务层用 BEM：所有页面级模块都以
.page-home、.search-bar开头，内部严格遵循__和-- - 通过 CSS 预处理器（如 Sass）控制 import 顺序：
@import "oocss/base"在前，@import "bem/modules"在后，避免基础类被业务覆盖
:is() 和 [class*="..."] 不是 BEM/OOCSS 融合方案
有人试图用现代选择器“绕过命名冲突”，比如写 :is(.btn, .button) 统一设置字体，或用属性选择器匹配 [class*="__icon"] 提取图标样式。这类做法看似灵活，实则破坏可维护性：
立即学习“前端免费学习笔记（深入）”；
-
:is()会提升选择器特异性，让后续覆盖更难；且无法表达“仅当.btn和.button具备相同语义时才生效”这一前提 -
[class*="__icon"]匹配到.header__icon、.button__icon、甚至.icon-wrapper__icon--hidden，样式污染风险极高 - 构建时无法 Tree-shake 未使用的 BEM 元素，CSS 包体积失控
真正需要警惕的是“命名自由化”——当工程师开始纠结“这个 icon 类该叫 .icon-btn 还是 .button__icon”，说明设计约束已经松动。BEM 的价值不在语法，而在强制你回答：“它属于哪个块？它是否能脱离这个块独立存在？” 这个问题比任何命名规范都重要。
