bem在spa中是防止样式失控的必要约束而非可选项，它通过命名规范（如tab-list__item--active）显式声明作用域，解决多人协作、ssr、微前端中的类名冲突与状态错乱问题。
BEM 在现代 SPA 中不是“有没有用”的问题，而是“用不用对”的问题——它本身不解决所有 CSS 痛点，但能显著压住样式失控的临界点，尤其在多人协作、SSR、微前端等真实生产场景下。
为什么 SPA 里 classList.toggle('active') 容易引发状态错乱
SPA 组件频繁挂载/卸载，document.querySelector('.active') 这类泛化选择器极易跨组件误匹配；服务端直出的 HTML 若含 active 类，客户端 hydration 后再执行 classList.toggle('active')，会导致视觉与 DOM 属性不同步、可访问性失效、甚至页面闪烁。
使用 BEM 后，状态绑定到具体业务上下文：tab-list__item--active 或 search-form__submit--disabled，配合 JS 同时操作 element.disabled = true 和 element.classList.add('button--disabled')，才能确保 SSR 与客户端状态一致。
- 不要只加类不设属性，键盘用户仍能聚焦并触发禁用按钮
- 不要只设属性不加类，CSS 样式就丢失了
- 避免写
.button--disabled:disabled这种冗余组合，它既不可靠（伪类可能被覆盖），也违背 BEM 语义优先原则
修饰符叠加时为什么不能写成 button--primary--large--disabled
这种连缀写法本质是把 BEM 当成了样式开关集合，破坏了修饰符的独立性与可组合性。浏览器解析没问题，但人脑维护成本陡增：无法单独复用 button--large，主题系统也无法按状态粒度接管，CI 阶段更难用 stylelint-selector-bem-pattern 拦截。
正确做法是用空格分隔多个布尔型修饰符：button--primary button--large button--disabled。
- 每个修饰符只表达一个明确状态或角色（
--primary是主操作，不是--blue） - 支持任意组合，且可被单独覆盖或移除
- VS Code 插件
BEM Tools能自动补全__和--，减少手误
老项目不重命名也能受益的关键动作
全量重命名成本高、风险大，但渐进式落地效果明确：新组件从第一天起就用 BEM 命名，修 bug 时顺手升级旧选择器，就能持续收口。
例如把 .sidebar ul li a 改为 .sidebar__item-link，不仅定位变快，后续抽离为 npm 包时，下游项目一眼看懂语义。
- 新增代码必须守规矩：块名带业务语义（
search-panel），不叫container或box - 老代码保留路径：搜
card还能找到所有相关样式，但新模块统一用product-card__price - 禁止嵌套选择器（如
.card .title），否则 DOM 结构一变，样式就失效
真正容易被忽略的不是语法细节，而是边界感：BEM 只管有明确业务归属的组件，u-text-center 这类工具类、theme-dark 这类全局变量、reset-list 这类归一化规则，硬塞进 BEM 结构只会让命名膨胀且语义失焦。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
