BEM约束命名与结构，OOCSS约束抽象逻辑与复用方式；BEM要求类名严格反映DOM层级和职责，OOCSS只强调对象可复用而不拘泥语义。
BEM 和 OOCSS 不是“选哪个更好”的关系，而是解决不同层级问题的方案：BEM 主要约束命名与结构，OOCSS 主要约束抽象逻辑与复用方式。混用不冲突，但错位使用反而加剧混乱。
类名设计是否强制语义化？
BEM 要求类名严格反映 DOM 层级和职责：menu__item--active 中 menu 是块、item 是元素、active 是修饰符，三者缺一不可。这种命名自带上下文，即使脱离 HTML 也能猜出用途。
OOCSS 不约束类名形式，只强调“对象”可复用——.btn、.card、.bb-c 都算合法，重点在是否能跨模块复用，而非是否带语义。
- BEM 类名长但意图明确，适合多人协作或长期维护项目
- OOCSS 类名短但易歧义，
.f16这类工具类若无文档支撑，半年后连自己都难定位作用 - 真实项目中常见折中：用 BEM 命名组件（
search-form__input），内部用 OOCSS 工具类微调（search-form__input f16 c666）
样式复用是靠继承还是靠组合？
OOCSS 的核心是“分离结构与皮肤”，比如把按钮的尺寸、颜色、圆角拆成独立对象：.btn（结构）、.btn--primary（皮肤）、.btn--large（变体）。它们可以自由组合：class="btn btn--primary btn--large"。
立即学习“前端免费学习笔记（深入）”；
BEM 默认不鼓励这种叠加，它更倾向为每个视觉状态定义完整类名：button--primary、button--primary-large，避免运行时依赖多个类共同生效。
- OOCSS 组合灵活，但容易出现“类爆炸”，
btn btn--primary btn--large btn--rounded btn--shadow一串写下来，调试成本高 - BEM 类名冗余但稳定，改一个状态只需换一个类，不会意外影响其他维度
- 关键差异在 CSS 选择器权重：OOCSS 多靠单类名，BEM 多用单类名+双下划线，两者都规避了嵌套选择器，这点倒是一致
HTML 是否承担样式职责？
OOCSS 明确要求 HTML 承担更多样式决策：你得手动写 class="media media--rev" 来翻转布局，而不是靠 JS 或父容器控制。这提升了 HTML 的表达力，但也增加了模板复杂度。
BEM 更克制——HTML 只声明“我是一个菜单项”，样式细节由 CSS 决定；menu__item 本身不暗示方向、尺寸或主题，这些全交给修饰符或父级上下文处理。
- OOCSS 的 HTML 更“胖”，适合设计系统驱动的项目（如 Bootstrap 4+ 的 utility-first 思路）
- BEM 的 HTML 更“瘦”，适合组件化程度高、CSS-in-JS 或 scoped style 广泛使用的项目（如 Vue SFC）
- 注意陷阱：OOCSS 若滥用
media--rev这类修饰符，却没在 CSS 中定义.media--rev，就会留下死类名，上线后难以清理
真正难处理的不是 BEM 和 OOCSS 本身，而是团队对“什么算一个对象”“什么该抽成修饰符”的认知偏差。一个 card 在 A 同学眼里是块，在 B 同学眼里可能是 layout__section + 多个 text-block。这类分歧不会被任何命名规范自动解决，得靠设计系统文档和 PR review 规则兜底。
