bem的业务语义必须严格绑定block名和modifier值，禁止视觉或技术状态命名；element名不得含业务上下文；modifier须可被js直接识别并触发业务逻辑；react/vue中应通过常量和工具函数收敛语义。
业务含义必须落在Block名和Modifier值上
BEM不接受“视觉快照”或“临时标签”，业务语义只能通过Block名（如payment-form、checkout-step）和Modifier值（如--pending、--failed、--guest）承载。写button--red或card--v2等于放弃BEM的可维护性——前者绑定颜色值，后者无法被JS识别状态。
-
payment-form__submit-button--processing✅ 表达明确业务阶段，CSS可映射$state-processing变量，JS可监听payment-form__submit-button--processing做禁用逻辑 -
payment-form__submit-button--loading❌ “loading”是技术状态，不是业务状态；用户看到的是“正在扣款”，不是“浏览器在发请求” - Modifier值禁止使用
--new、--beta等不可预测词，它们无法参与主题切换或自动化测试
Element命名不能带业务上下文
card__title合法，card__product-title非法——Element名只描述自身角色，不携带父级或业务语义。一旦把业务词塞进Element，就等于把组件耦合到特定场景，后续复用到用户列表页时，card__user-name就得重写样式。
- 正确做法：统一用
card__title，靠Block名区分语义：product-card__titlevsuser-card__title - 如果标题内容结构差异大（比如产品标题含价格，用户标题含头像），说明这不是同一个Block，该拆成
product-summary和user-brief - Element名中出现
__icon、__badge没问题，但__status-icon就过界了——状态属于Modifier，图标属于独立Block
Modifier要能被JavaScript直接读取和响应
一个Modifier是否合格，看它能不能被element.classList.contains('block__element--modifier')安全判断，并触发对应业务逻辑。写form--dark不如form--guest-mode，因为前者只改颜色，后者能同步关闭邮箱验证、跳过地址校验。
- 常见可落地的业务Modifier：
--guest、--trial、--expired、--review-pending - 避免用
--mobile这类设备修饰符——业务逻辑不该由屏幕宽度决定，而应由用户身份或流程阶段决定 - 多个Modifier并列使用：
order-summary order-summary--guest order-summary--has-coupon，不要合并成order-summary--guest-has-coupon
React/Vue里怎么保证业务语义不丢失
直接拼字符串className={`card__title ${isGuest ? 'card__title--guest' : ''}`>会让业务逻辑散落各处。更稳的方式是把Modifier映射封装进组件内部，让调用方只传业务参数。
- 定义常量：
const MODIFIERS = { guest: 'card--guest', trial: 'card--trial' }; - 用
clsx收敛逻辑：className={clsx('card', MODIFIERS[mode])} - 关键点：Block名（
card）必须在组件顶层声明为常量，不能在JSX里硬编码，否则重构时漏改一处就导致样式断裂
--for-admin或--only-on-homepage，往往意味着这个Block本就不该存在，或者该拆分。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
