BEM能直接掐断冗余选择器生成，因其强制扁平命名（如card__title），使相同样式复用同一类名、CSS规则只写一次，并为PurgeCSS提供稳定命名模式以精准删除未用规则。
为什么BEM能直接掐断冗余选择器的生成
BEM不是靠“压缩”或“合并”来减体积，而是从写法源头堵住重复规则的出口。传统写法中，.header-nav a 和 .footer-nav a 即便样式完全一样，编译后也会产出两套独立 CSS 规则；BEM 强制改用 header-nav__link 和 footer-nav__link，但更关键的是：当多个结构相似的组件（比如卡片列表）都用 card__title 时，CSS 只需定义一次 .card__title，所有实例复用同一声明。
浏览器匹配效率提升只是副产品，真正省的是规则数
单类名如 card__content 匹配是哈希查表，O(1)；而 .card .content p 要从右往左逐层回溯父元素，DOM 深时开销明显。但这只是运行时收益——BEM 对体积的实质性影响，在于它让构建工具（尤其是 PurgeCSS）能精准识别“哪些类真的被用了”。PurgeCSS 不理解语义，只认字符串；BEM 提供稳定、可预测的命名模式（block__elem--mod），让它敢删、能删准。
- 动态拼接类名（如
className={`${block}__${el}--${mod}`}）会让 PurgeCSS 看不到运行时实际值，只能保守保留整块规则 - 第三方组件未显式声明类名（如
class="van-button"），对应样式就会被误删 -
content配置漏掉 JSX/Vue 模板路径，等于关掉了 PurgeCSS 的眼睛
修饰符滥用是体积反弹的头号原因
--modifier 本身不增体积，但失控就会爆炸。比如为每个像素级尺寸写 button--size-12、button--size-16，或为每种颜色写 button--bg-red、button--bg-blue，结果 CSS 里全是碎片化声明，且 PurgeCSS 很难推断哪些组合真被用了。
- 真正该用修饰符的场景极少：
button--primary、input--error、card--disabled—— 语义明确、组合有限、总数建议 ≤5 个 -
button--disabled必须和button同时出现，否则构建工具无法建立上下文，tree-shaking 失效 - 禁止
button--primary-margin-left-20这类“一义多职”类名，PurgeCSS 无法识别使用意图，只能白名单硬保
Block 边界模糊会悄悄破坏 BEM 的收益
一个 search-bar block 的子元素必须严格限定在它的根 DOM 范围内，比如 search-bar__input、search-bar__results。一旦出现 search-bar__results__item，就违背了 Element 只能直属于 Block 的原则——这不仅让语义断裂，还会导致 PurgeCSS 无法关联上下文，tree-shaking 失效，最终体积不降反升。
最容易被忽略的一点：BEM 的价值不在类名本身，而在于它用命名约束倒逼你放弃易引发冗余的写法。比如你不再能靠 .list .item 控制所有列表项，就必须把共性提取成 list-item，自然就减少了重复定义。这种“被迫收敛”，才是它压低体积的真实机制。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
