BEM能直接约束UI视觉一致性，因其强制将样式归属写进类名本身，如button__text--large明确属于button块的text元素且启用large变体，避免跨块覆盖或DOM结构变动导致错乱；所有同块元素共用基础排版规则，修饰符仅控制可组合的状态变体，设计意图显式、可预测、可维护。
为什么BEM能直接约束UI视觉一致性
因为BEM强制把样式归属写进类名本身，而不是靠CSS层叠顺序或父级选择器猜意图。比如button__text--large这个类名，不看CSS文件也能确认：它只属于button块、是text元素、启用large变体——不会被card__text--large意外覆盖，也不会因外层.container缩放而错乱。
常见错误现象：.title在多个组件里重复定义字体大小，结果表单里的标题和弹窗里的标题字号不一致；换成form__title和modal__title后，各自独立控制，视觉差异变成显式声明而非隐式继承。
- 所有
button块下的__text元素必须共用一套基础排版规则（如line-height、font-weight），修饰符只改尺寸或颜色 - 禁止用
button--primary控制背景色的同时，又用button--small改padding——这会让“主按钮+小尺寸”组合无法预测 - 团队需约定哪些属性归块级（如
--button-bg）、哪些归修饰符（如--button-bg-primary），避免同一视觉特征在多处定义
如何让BEM类名真正驱动UI设计系统
BEM不是命名游戏，而是把设计语言翻译成可执行的代码约束。比如设计稿里“主按钮”要求圆角4px、阴影2px、禁用态灰度#999，这些就该直接映射为button--primary和button--disabled的CSS规则，而不是靠JS动态加is-primary这种模糊类名。
实际协作中，最常踩的坑是修饰符语义漂移：button--loading本该只控制图标旋转和禁用交互，但有人顺手在里面加了opacity: 0.7，导致后续想单独控制透明度时必须覆盖它。
立即学习“前端免费学习笔记（深入）”；
- 每个
--modifier只响应一个明确业务状态（--disabled、--expanded），不混入样式细节 - 颜色/尺寸等具体值不进修饰符名，用
button--primary而非button--blue，否则换主题时要全局替换类名 - 设计系统文档里每个修饰符必须标注对应视觉表现，例如
card--elevated=box-shadow: 0 2px 8px rgba(0,0,0,0.1)
怎样避免BEM变成新一层维护负担
长类名、嵌套限制、工具链适配——这些不是BEM本身的问题，而是没对齐工程节奏。重点不是“写对BEM”，而是让BEM规则自动生效。
常见错误现象：新人手写header__logo__icon被工具报错，但没人告诉他该拆成logo独立块；或者VS Code里敲button没补全提示，结果手动拼错button__icont。
- 用
stylelint-config-bem在保存时拦截__嵌套、--位置错误等硬性违规 - 组件顶部统一声明
const BLOCK_NAME = 'user-card'，所有子类名用${BLOCK_NAME}__avatar生成，杜绝手误 - 禁用构建工具的
mergeLonghand优化，否则button button--primary button--disabled可能被压缩丢掉一个修饰符
BEM和设计稿对不齐时怎么办
设计稿里一个“带图标的大号主按钮”在开发时往往拆成多个BEM类：button button--primary button--large button__icon。这不是冗余，而是把设计原子化——图标位置、尺寸、颜色全部由button__icon控制，和按钮状态解耦。
容易被忽略的是：设计系统里“大号”可能指高度、内边距、字体三者联动，但BEM要求这三者必须绑定在同一个--large修饰符下，不能一个写在button--large，一个写在button__text--large。
- 设计变更时，只改
.button--large规则，所有使用它的实例自动同步 - 若某处需要“大号按钮但小号图标”，说明
button__icon本身应支持--small修饰符，而不是破坏BEM结构去硬调 - 第三方组件（如Ant Design的
Button）不要强行套BEM类名，而是在它外部用form__submit-button组织布局关系
