bem在原生html/css中硬编码类名会导致维护困难、语义漂移和样式污染；react/vue中应通过block常量+clsx管理类名，css modules需配合eslint校验确保block边界隔离。
原生HTML/CSS里直接套用BEM类名会出什么问题
很多人把BEM当“命名格式模板”，在纯HTML里硬写 .card__header--expanded，结果上线后发现JS控制状态时总要同步改两处：一处是HTML里的class字符串，另一处是JS里el.classList.toggle("card__header--expanded")。一旦组件重构（比如card改成product-card），所有地方都得手动搜替换，漏一个就样式错位。
更隐蔽的问题是语义漂移：.btn--primary在按钮组件里表示品牌主色，但某天产品经理说“登录页的按钮要蓝底白字，注册页要绿底白字”，开发者就可能随手改成.btn--login-primary、.btn--register-primary——这已经违背BEM修饰符“可枚举、可预测”的前提，后续根本没法维护。
- Block名必须全局唯一且稳定，不能随页面场景动态拼接
- Modifier值禁止带业务上下文（如
--login、--mobile-only） - Element名只描述功能（
__icon、__content），不描述位置或条件
React/Vue里用BEM怎么避免className硬编码
在框架中写className="button__text button__text--large"属于反模式。它把样式逻辑锁死在模板层，既无法被TypeScript校验，也绕过了CSS Modules的作用域保护。
正确做法是让组件自己管理Block名边界：
- 每个组件顶部定义常量
const BLOCK = "user-avatar"，所有类名基于它生成 - 用
clsx统一处理条件逻辑：clsx(`${BLOCK}__image`, { [`${BLOCK}__image--loading`]: isLoading }) - 禁止在JSX里出现任何未声明的BEM字符串，比如
"avatar__img"（没声明BLOCK）或"user-avatar__img--round"（修饰符没在CSS里定义）
这样即使未来把user-avatar重构成profile-pic，只需改一行BLOCK常量，所有派生类名自动更新。
CSS Modules + BEM如何防止跨Block样式污染
CSS Modules本身能哈希化类名，但BEM的结构意义容易被忽略。常见错误是在Button.module.scss里写.modal__close { display: none; }——这等于把Modal的样式逻辑塞进Button文件，破坏了Block的独立性。
真正起作用的是构建时的约束：
- 用
eslint-plugin-css-modules校验：只允许Button.module.scss里出现以button开头的类名（button__icon、button--disabled） - 媒体查询必须收口到统一断点文件，禁止在Block内写
@media (max-width: 768px) { .button__text { font-size: 12px; } } - 第三方库样式（如Ant Design）必须用wrapper隔离：
<div class="legacy-wrapper"><datepicker></datepicker></div>，再通过.legacy-wrapper .ant-picker局部覆盖
老项目增量接入BEM时最该守住的三条线
不是所有旧代码都能立刻重写，但以下三处必须立即卡住，否则BEM会变成新混乱的源头：
- 禁止新增
.clearfix、.hidden这类全局工具类——改用is-hidden等语义化控制类，并在CSS里用.card.is-hidden { display: none; }关联 - 所有新组件必须有明确Block边界，不允许出现
.section-3__title这种靠视觉位置命名的类（section-3不是功能块，只是临时分组） - 图标类名必须绑定到宿主Block：
.search-form__icon合法，.icon-search非法；哪怕多个组件共用同一SVG，类名也必须分离
真正的难点不在语法，而在于让团队相信：BEM的约束不是为了好看，而是为了让「改一个按钮颜色」这件事，永远只发生在button这个文件里，而不是散落在HTML、JS、SCSS、甚至第三方库的覆盖规则中。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
