BEM命名能直接当文档看，因其类名明确表达“谁（块）、在哪儿（元素）、干啥（修饰符）”，如card__header--large表示card组件的大号头部，btn--primary表明按钮的基础样式与主态修饰，避免全局冲突。
为什么BEM命名能直接当文档看
因为类名本身已经说明了「谁、在哪儿、干啥」，不需要额外注释。比如 card__header--large 一眼可知：这是 card 组件的头部，且是大号变体；而 btn btn--primary 明确区分了基础样式和修饰状态，不会和全局 header 或其他 btn 冲突。
常见错误是把 BEM 当成“多写几个下划线”的形式主义，结果写出 user-card__user-info__name-text 这种嵌套过深的类名——它违反了 BEM 的「单一职责」原则，也失去了可读性。
- BEM 不要求每个 HTML 元素都带 class，只对需要样式或 JS 绑定的节点加
-
__（双下划线）只能用于组件内部子元素，不能跨组件使用，比如modal__card__header是错的 -
--（双横线）修饰符必须依附于一个基础块或元素，单独用card--large可以，但large不行
怎么避免BEM写成“命名焦虑”
核心是先画清组件边界，再命名。一个 card 是独立块，它的头、体、脚就是 card__header、card__body、card__footer；如果里面有个按钮，就叫 card__action-btn，而不是 btn card-btn——后者破坏了作用域隔离，也埋下了样式污染隐患。
真实项目里最常踩的坑，是把语义化标签当命名依据：<header></header> 就写 header，<aside></aside> 就写 aside。这会让 CSS 失去上下文，也导致复用困难。
立即学习“前端免费学习笔记（深入）”；
- 块名用名词，如
search、teaser、filter-panel，不用动词或形容词开头 - 元素名也用名词，聚焦功能而非视觉，比如用
search__input而非search__textbox - 修饰符优先用业务状态，比如
search--loading、teaser--featured，少用纯视觉描述如--blue
CSS-in-JS 或 Tailwind 下还要不要BEM
要，但用法得调。在 CSS-in-JS 中，BEM 主要保留在 class 名生成逻辑里，比如 Emotion 的 css + cx 组合，仍靠 card__header 这类 key 来组织样式模块；Tailwind 则反其道而行——不用 BEM 类名，但要用 BEM 思维组织 @layer components 和自定义 @apply 块，否则很快会变成一堆散装 flex p-4 bg-gray-100 rounded-lg，根本看不出哪段属于哪个组件。
典型误操作：在 Tailwind 项目里还手动写 class="card__header"，然后配一堆 .card__header { @apply ... }。这既没发挥 utility 优势，又丢了 BEM 的结构价值。
- CSS-in-JS 中，BEM 是组织
classNames的逻辑，不是硬编码 class 字符串 - Tailwind 下，BEM 思维体现在
component层的抽象粒度，比如定义@layer components { .btn { @apply px-4 py-2 rounded; } }，再用btn btn--primary这样的约定控制扩展 - 所有方案里，
js-前缀（如js-toggle-menu）仍建议保留，专供 JS 选择器，和样式类彻底分离
团队落地时最容易被忽略的一点
不是命名规则本身，而是「块的粒度是否一致」。有人把整个首页当一个 home 块，结果下面塞了二十个 home__xxx；也有人把一个图标按钮拆成 icon-btn、icon-btn__icon、icon-btn__label 三层——两种都让 BEM 失效。
判断块是否合理，就看它能否独立复用、是否有明确输入/输出（哪怕只是 props）、是否具备完整交互闭环。一个真正可维护的 BEM 体系，往往从三个典型块开始：布局容器（layout）、内容区块（card、teaser）、功能控件（dropdown、tabs）。
一旦块的边界模糊，后面所有命名、复用、交接都会变重。这点比记清 __ 和 -- 的区别重要得多。
