应根据团队协作节奏、项目迭代频率、组件复用程度和维护成本选择：BEM适合组件化项目，OOCSS适合大型长期系统，SMACSS适合中大型弹性架构。
选 CSS 架构模式不是比谁“更高级”，而是看团队当前的协作节奏、项目迭代频率、组件复用程度和维护成本承受力。BEM 适合快速落地、边界清晰的组件化项目；OOCSS 对大型长期演进系统更友好，但要求团队有抽象意识；SMACSS 则在中大型项目里提供结构弹性，但容易因分层模糊而退化成“五类文件夹”。
什么时候该用 BEM：你正在写 Vue/React 组件库或需要强隔离的 UI 模块
BEM 的 block__element--modifier 命名直接映射到组件层级，HTML 和 CSS 的耦合是显式且受控的。
- 适用场景：组件粒度明确（如
card、modal）、团队成员 CSS 经验不均、需快速交付可复用 UI 包 - 关键优势：命名自带作用域，
header__logo不会和另一个logo冲突；禁用嵌套选择器，样式权重扁平 - 容易踩的坑：滥用修饰符导致类名爆炸（如
button--primary--large--disabled--loading）；把状态逻辑（is-open）硬塞进 BEM 修饰符，违背其“静态变体”本意 - 参数差异：BEM 不强制前缀，但建议统一加命名空间（如
el-button__text），避免和第三方库冲突
OOCSS 适合什么项目：你有大量视觉一致但结构不同的容器（表单、卡片、弹窗）要反复组合
OOCSS 的核心不是命名，而是把“结构”（.box）和“皮肤”（.box--success）拆开，靠 class 组合驱动样式。
- 适用场景：后台系统、CRM、ERP 等以表单和数据展示为主的中后台项目；已有大量散装 CSS 需收敛重构
- 为什么这样做：减少重复声明（padding/margin/border-radius 只写一次），提升主题切换能力（换 skin 类即可）
- 常见错误现象：把“结构类”写成具体语义（如
.user-card），失去复用性；过度抽象导致开发者记不住哪个类负责哪段结构 - 性能影响：class 越多，HTML 体积略增，但现代浏览器对 class 数量不敏感；真正影响性能的是无节制的
@import或未压缩的 CSS 文件
SMACSS 分层是否必要：当你开始为“页面级布局”和“组件级样式”设不同维护责任人时
SMACSS 的五类（Base / Layout / Module / State / Theme）本质是职责切分，不是文件夹命名规则。
立即学习“前端免费学习笔记（深入）”；
- 使用场景：多人协作的 Web App，Layout 层由前端架构师维护，Module 层由业务组各自负责，State 层需和 JS 状态管理对齐
- 参数差异：推荐用前缀强化语义——
.l-header（layout）、.is-hidden（state）、.t-dark（theme），否则分层很快失效 - 容易被忽略的地方：Base 层必须包含重置 + 默认 typography，否则 Layout 层的
rem计算会失准；State 类（如.is-loading）应只控制 display/opacity/pointer-events，不掺杂颜色或尺寸 - 兼容性影响：SMACSS 对 CSS 预处理器无强依赖，但用 PostCSS 插件（如
postcss-smacss）能自动校验前缀使用
真正难的不是选哪种模式，而是坚持一种模式下的约束力。BEM 项目里混进 .btn-primary，OOCSS 项目里出现 .profile-card__avatar--round，SMACSS 项目里把所有样式都扔进 module.css——这些才是让架构失效的临界点。
