BEM难维护的根本原因是缺乏设计系统支撑。需三层收敛：原子类提供语义接口，BEM限定作用域，设计令牌统一管控变量；所有修饰符须可组合、响应式需带断点前缀；构建时用linter校验命名合法性。
为什么直接套用BEM命名却还是样式难维护
因为BEM只是命名约定，不是设计系统。很多人写__header、--large，但没约束这些修饰符在哪些组件里能用、值域是否统一、响应式怎么分层——结果是btn--primary和card--primary的蓝色压根不是同一个$color-primary变量。
真正起作用的是三层收敛：原子类只暴露语义化接口（如text-sm、bg-surface），BEM块名限定作用域（form-input__control），而所有颜色/间距/圆角全部从设计令牌（Design Tokens）生成，不手写具体数值。
- 别在
button__text里写font-size: 0.875rem，改用font-size: var(--fs-sm) -
__element名必须对应真实DOM节点，避免card__shadow这种伪元素抽象（阴影应由shadow-xs原子类控制） - 所有
--modifier必须可组合：btn--primary btn--disabled要能同时生效，不能靠&.btn--disabled覆盖btn--primary的背景色
CSS自定义属性如何与BEM块解耦
把--color-bg这类变量塞进.card里，等于把设计系统逻辑锁死在组件内部。正确做法是顶层注入设计令牌，BEM块只做语义映射。
比如:root定义--color-surface: #fff，而.card只需声明background-color: var(--color-surface)——这样换主题时只改:root，不用碰任何BEM类。
立即学习“前端免费学习笔记（深入）”；
- 禁止在
.block__element里声明--custom-var，所有自定义属性必须在:root或主题类（如.theme-dark）中统一管理 - BEM类里只出现
var(--spacing-md)这类令牌引用，绝不出现var(--card-padding)这种组件专属变量 - 用
@supports (color: oklch(0 0 0))做色彩空间降级时，oklch()值必须来自同一组设计令牌，不能为BEM块单独写一套
原子类该封装到什么粒度才不反模式
原子类不是越细越好。ml-1、mt-2这种工具类在React/Vue里容易失控，但全删掉又退回到CSS地狱。关键在“语义边界”：只封装设计系统明确定义的、跨组件复用的视觉单元。
比如间距系统只提供space-x-4（对应--spacing-lg），不提供ml-16；文字层级只用type-heading-lg，不用text-2xl。
- 禁用纯数值类：
px-3、h-8——它们绕过设计令牌，破坏一致性 - 允许组合但禁止嵌套：可以
btn type-button-primary space-x-2，但不要btn-primary-lg这种复合原子 - 响应式原子必须带断点前缀：
sm:pt-4有效，pt-sm无效（后者无法表达“仅在sm断点应用”）
如何让BEM类名在构建时自动校验合法性
靠人眼检查menu__item--active是否符合规范？太晚了。应该在写代码阶段就拦截错误。
用PostCSS插件postcss-bem-linter或ESLint插件stylelint-selector-bem-pattern，配置规则强制__只能出现在块名后、--必须跟在__后且不能连续出现两次。
- 报错示例：
.card__header--hover--active（双--）、.btn_element（下划线非法） - CI中加入
npx stylelint "**/*.css" --fix，把命名问题卡在提交前 - VS Code装
PostCSS Language Support插件，实时高亮.block__element-modifier这种错误结构
最难的不是写对BEM语法，而是让每个__element都对应一个真实的设计决策——比如为什么tooltip__arrow必须是position: absolute，这个约束得写进设计系统文档，而不是藏在某个CSS文件的注释里。
