选BEM还是OOCSS取决于样式变体的控制权归属：OOCSS适合HTML模板主导样式决策（如按钮颜色、尺寸），BEM适合JS驱动状态且需强语义隔离的组件场景；前者类名短、复用高但易歧义，后者类名长、自解释但冗余，混用时建议BEM管组件外壳、OOCSS管内部微调。
选BEM还是OOCSS，不是风格偏好问题，而是你项目里「谁控制样式变体」这个权责是否清晰。如果HTML模板频繁决定按钮颜色、尺寸、方向，OOCSS更顺手；如果组件状态（如 disabled、loading）由JS驱动且需强语义隔离，BEM更稳。
类名是否必须反映DOM结构？
BEM强制类名携带上下文：search-form__input--large 一眼可知它属于 search-form 块、是其 input 元素、处于 large 状态。即使抽离HTML，也能反推结构。OOCSS不关心这点：input-large 或 f16 只表达“大”或“字号16”，不绑定父级，可跨块复用，但也意味着你得靠文档或约定才知道它该用在哪儿。
常见错误现象：团队新人直接给 <div class="f16 c333"></div> 加样式，结果发现 f16 在另一处被改成 font-size: 18px，全局失效却查不到源头。
- BEM类名长但自解释，适合多人协作、长期维护、组件库对外暴露
- OOCSS类名短但易歧义，适合内部工具类体系成熟、有配套设计系统文档的项目
- 混用时建议：组件外壳用BEM（
card、card__header），内部微调用OOCSS（card__header f16 bb-c）
修饰符是独立类还是组合类？
BEM的修饰符是完整语义单元：button--primary 和 button--disabled 是两个互斥状态，不能同时生效；需要组合时写成 button--primary-disabled，CSS里单独定义。OOCSS则鼓励叠加：btn btn--primary btn--large，每个类只管一个维度，靠CSS层叠生效。
立即学习“前端免费学习笔记（深入）”；
性能影响：OOCSS叠加多类名会增加HTML体积和选择器匹配开销（虽小但可测）；BEM单类名更轻，但状态爆炸时（如 button--primary-large-rounded-shadow）维护成本陡增。
- 调试陷阱：OOCSS中
btn--primary被覆盖，可能是因为btn基础类里用了!important，而叠加类没声明足够权重 - BEM中改一个状态就得新增类名，CI流程若没校验类名白名单，容易漏写CSS规则导致视觉丢失
- Vue/React组件内用
className={clsx('button', isPrimary && 'button--primary')}比拼接字符串更安全
HTML要不要承担样式决策？
OOCSS明确让HTML“胖起来”：<article class="media media--rev"></article> 直接声明布局翻转，CSS只需实现 .media--rev 规则。BEM则要求HTML保持“瘦”：<article class="article"></article>，翻转逻辑交给父容器修饰符或JS控制类（如 section--reversed）。
容易踩的坑：OOCSS项目里写了 media--rev 却忘了在CSS中定义，上线后该翻转的模块永远不翻转，且死类名难以通过工具扫描清理。
- 设计系统驱动型项目（如基于Figma Tokens生成CSS）更适合OOCSS，因为视觉属性可直出为类
- 组件化程度高、大量使用CSS-in-JS或scoped style的项目，BEM更自然——样式逻辑收在组件内部，HTML无需暴露表现细节
- Bootstrap 5已转向“utility-first + component wrapper”混合模式，本质是OOCSS思路+有限BEM封装
BEM和OOCSS真正难的不是命名规则本身，而是团队对「样式所有权」的共识：谁决定一个按钮是圆角还是直角？是设计师给Token，前端生成工具类（OOCSS路径）；还是组件API定义 rounded prop，渲染对应BEM修饰符（BEM路径）。选错路径，后期重构成本远高于初期学习成本。
