BEM 通过 block__element--modifier 命名约定实现样式作用域隔离，避免全局类名冲突；需严格执行命名规范、限定第三方样式影响范围，并接受合理类名冗余以保障可维护性。
为什么直接写 .button 会导致样式污染
全局类名没有天然作用域，只要两个组件都用了 .button，CSS 就会叠加生效。常见现象是：A 组件更新了 .button 的 padding，B 组件的按钮突然变高了；或者第三方 UI 库升级后，覆盖了你自定义的 .header 背景色。
根本原因不是 CSS 写得不好，而是选择器太宽泛。浏览器不关心“这是谁的按钮”，只认“有没有匹配 .button”。
- 所有跨团队协作、长期迭代的项目，都该默认把类名当作可能被复用/冲突的公共资源
-
:global或!important是临时止血，不是隔离方案 - 单文件组件（如 Vue SFC）的
scoped只对当前文件有效，无法解决第三方库或 JS 动态插入的 DOM 样式问题
BEM 命名怎么真正起作用：三段式不是摆设
BEM 的 block__element--modifier 结构，本质是用命名约定模拟命名空间。它不依赖工具，但必须严格执行，否则和乱写没区别。
比如一个搜索框组件：
错误写法：
.search input—— 一旦页面出现第二个input，就可能被误选中正确写法：
.search__input—— 元素归属明确，不会跨 block 干扰-
block对应独立功能单元（如.card、.navbar），不能嵌套太深（避免.pagesectionheader__title） element必须属于且仅属于某个block，不单独存在（.searchinput不该在.modal里复用）--modifier只改变外观，不改变结构（.button--primary可以和.button--small共存，但不要写.button--hidden来替代display: none）
遇到动态类名或第三方组件怎么办
JS 拼接类名、框架自动注入的 class（如 React 的 css-module 或 Ant Design 的 ant-btn）、服务端渲染的静态 HTML，都可能绕过 BEM 约束。
这时重点不是“禁止用”，而是“控制影响范围”：
- 对第三方组件，用属性选择器限定上下文：
.article-content [class^="ant-"]比全局.ant-btn安全得多 - JS 动态添加的类，统一走 BEM 命名（如
el.classList.add('tooltip--visible')），别用'active'这种裸名 - 如果必须覆盖第三方样式，优先用更具体的父级 BEM 类做前缀：
.profile-card .ant-input，而不是直接重写.ant-input - 工具层可加 ESLint 插件（如
stylelint-selector-bem-pattern）校验命名，但别指望它发现所有运行时拼接
性能和维护成本的真实代价
BEM 类名变长是事实，但现代 gzip 对重复字符串压缩效率很高，实际 CSS 体积增长几乎可忽略。更大的成本在人脑——写错一段 __ 或 --，调试时就要多花两分钟定位。
- 不要为了“简洁”缩写 block 名（
.btn→.btn__txt），这等于放弃命名空间意义 - 修改一个 element 时，检查所有用到它的 modifier 是否仍合理（比如
.list__item--selected在列表支持多选后，语义就弱了） - BEM 不解决“样式逻辑混乱”，只解决“命名冲突”。如果一个
block内部样式耦合严重（比如.cardtitle强依赖.cardimage的 margin），问题还在设计层面
事情说清了就结束。真正难的从来不是记住 __ 和 --，而是在 PR 评审时，愿意为一行类名多点一次键盘，而不是想“先跑通再说”。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
