bem通过命名约束避免样式冲突和维护灾难：block（如card）为独立单元，element（如card__title）须依附block，modifier（如card--featured）表状态且不单独使用。
为什么BEM能避免样式冲突和维护灾难
大型网站样式失控，往往不是因为写了太多CSS，而是选择器层级太深、命名随意、组件复用时互相覆盖。BEM（Block-Element-Modifier）不靠魔法，只靠命名约束：所有类名都明确表达「属于哪个块」「是不是它的子元素」「当前是什么状态」。它不强制你用预处理器或工具链，纯CSS就能落地。
常见错误现象：.header .nav .item.active 这种嵌套选择器，在另一个页面引入同名.header时极易误伤；更糟的是团队里有人写.btn--primary，有人写.button-primary，时间一长谁都不敢删旧样式。
- Block（块）是独立功能单元，如
card、search-form，命名必须语义化，不带位置或样式暗示 - Element（元素）用双下划线连接，必须依附于Block，如
card__title、card__footer，禁止出现card__title__highlight这种嵌套Element - Modifier（修饰符）用双连字符，表示状态或变体，如
card--featured、button--disabled，必须和Block一起用，不能单独出现
BEM在真实项目中的写法细节
不是所有地方都适合硬套BEM。比如工具类（u-text-center）、重置类（reset-list）或全局主题变量（theme-dark），它们本身就不属于某个Block，强行塞进BEM结构反而别扭。
使用场景决定写法：组件库中推荐严格BEM；老项目增量改造时，可先从新模块开始，旧代码保留但禁止新增嵌套选择器；SSR或微前端环境下，BEM类名天然支持CSS Module的局部作用域，无需额外加hash后缀。
- HTML中每个元素最多只写一个Block相关的类，避免
class="card card--featured"这种冗余，直接用card--featured - Element类名必须包含Block前缀，禁止简写成
__title，浏览器不认这个语法，必须是完整card__title - Modifier不叠加使用，
button--primary button--large可以，但button--primary--large违反规范，语义模糊且难维护
和CSS-in-JS、CSS Modules混用时的坑
BEM类名本质是字符串，和构建工具无关，但和运行时样式注入方式有隐性冲突。比如用styled-components写const Card = styled.div.attrs({ className: 'card' })，再手动加card__body，就破坏了BEM的完整性——此时card__body实际由JS控制，而CSS文件里却还定义着它，后续想抽离成独立组件会卡住。
性能影响不大，但兼容性风险集中在动态类名拼接上：className={`${block}__${element} ${block}--${mod}`}这种写法容易漏空格或拼错大小写，尤其在TypeScript里没类型提示时，block变量若为undefined会导致类名变成undefined__title，浏览器静默忽略，样式丢失且无报错。
- React中优先用
clsx处理条件类名，而不是模板字符串拼接 - Webpack里启用
css-loader的modules: { auto: true }后，BEM类名会被自动加hash，此时需在JS中通过import styles from './Card.module.css'引用styles.card__title，而非硬编码字符串 - Vue单文件组件中，
<style scoped></style>已隔离样式，BEM仍有必要——它解决的是人脑理解成本，不是CSS作用域问题
哪些情况不该用BEM
BEM不是银弹。当项目里大量使用原子化CSS（如Tailwind）时，强行套BEM只会让HTML臃肿、开发节奏变慢；同理，纯静态营销页、一次性活动页，生命周期短、无长期维护压力，花时间设计Block命名得不偿失。
最容易被忽略的一点：BEM对设计师协作提出隐性要求。如果设计稿里把“搜索框”叫SearchBar，开发却定名search-form，后续对齐成本陡增。所以真正卡住落地的，往往不是技术，而是命名共识是否前置达成。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
