BEM在小型项目中不应盲目套用，仅当组件跨≥2个路由或父组件复用时才启用；纯页面独有样式可用单class，工具类与BEM可并存但需分层清晰。
不适用。BEM 是一种强约束的命名结构，它只在特定条件下带来收益，盲目套用反而增加认知和维护成本。
小型项目或原型页面直接用 BEM 反而拖慢开发
比如一个单页营销页、内部工具后台首页、临时活动页，DOM 结构简单、样式复用率低、团队规模小甚至只有 1 人维护——此时写 .hero__title--large 不如直接 .hero-title 或 .title-lg。BEM 的三层前缀（block__element--modifier）在这些场景下只是冗余字符串，编译后体积增大，DevTools 查看类名更费眼，且没人会跨文件复用这个“块”。
- 判断依据：CSS 文件总数
- 替代方案：语义化单类名（
.btn、.card）+ 工具类（.mt-2、.text-center）更轻量 - 风险点：强行套 BEM 容易催生
.page__section__header__logo这类非法嵌套，违反 BEM 原则且不可维护
React/Vue 组件内使用 BEM 需警惕 className 拼接失控
组件化框架中，className 往往动态拼接，BEM 要求每个 class 都带完整前缀，容易漏掉基础 block 类或 modifier 冲突。例如：button button--primary button__icon 缺了 button 就失效；button--primary button--outline 同时存在时，层叠顺序决定最终样式，但 BEM 不管这个。
PigX UI Pro 前端开发指南 - Vue 3 + TypeScript + Element Plus。当用户提到 PigX UI、PigX 前端、lgb-mgui 项目、Vue 3 企业级后台开发、Element Plus 后台开发时使用此技能。
- 必须配套工具：用
clsx或classnames动态组合，避免手写字符串拼接 - 禁止在 CSS-in-JS 中模拟 BEM 嵌套（如 Styled Components 里写
&__icon），这会让类名哈希化，失去 BEM 的可读性优势 - 真实陷阱：修饰符叠加没做互斥逻辑，比如
button--primary button--disabled同时存在，但 CSS 文件引入顺序导致--disabled样式被覆盖，问题难定位
与 Tailwind 等原子类共存时，BEM 容易变成“伪规范”
当项目已大量使用 flex、px-4、text-sm 这类工具类时，再给容器加 user-card、内容加 user-card__name，实际意义很弱——因为绝大多数样式来自原子类，BEM 类只剩语义标识作用，却仍要维护命名层级和文件组织。
立即学习“前端免费学习笔记（深入）”；
- 典型矛盾：设计师改个 padding，你得同时改
user-card__content的 CSS 和多个地方的px-4，BEM 并不解决这个问题 - 可行折中：仅对需要封装行为/状态的复合组件用 BEM（如
date-picker），纯布局容器用原子类 - 最易忽略：团队未约定“哪些组件走 BEM、哪些走原子类”，结果出现
card card__header text-xl font-bold这种混合写法，类名系统彻底失焦
BEM 的价值不在“用了没”，而在“是否真靠它收敛了样式归属、状态边界和复用路径”。大型项目里，一个 product-list__item--loading 能让所有人立刻理解这是列表项的加载态，且不会和 cart-item--loading 冲突——这种确定性，才是它不可替代的地方。但前提是，你得先有足够多的、真正需要隔离和复用的 UI 单元。
