bem 是大型 spa 中 css 长期可维护的必要约束而非加分项，它通过命名规范（如 header__title）显式声明作用域，避免类名冲突与样式污染，并需配合工具链、组织规范及合理分工（如与 css modules 协同）落地。
BEM 是大型 SPA 中 CSS 长期可维护的底线方案，不是加分项，而是防止样式系统崩溃的必要约束。
为什么 SPA 里类名冲突比多页应用更隐蔽、更难修复
单页应用中，多个路由组件常被同时挂载（比如侧边栏 + 主内容区 + 浮层），Header 和 DashboardHeader 可能共存于同一 DOM 树；若都用 .title，浏览器根本不管它们来自哪个模块，只按加载顺序和权重决定谁生效。BEM 的 header__title 和 dashboard-header__title 从命名上就切断了这种隐式耦合——类名即作用域，无需依赖构建工具或运行时隔离。
常见错误现象包括：margin 越调越大、审查元素时发现样式来自完全无关的文件、改一个按钮颜色结果所有 button 都变了。这些都不是 bug，是缺乏显式作用域声明的必然结果。
如何让 BEM 在 SPA 中不变成“写起来累、查起来懵”的负担
关键不是少写字，而是让机器帮你守规则：
- 用
stylelint-selector-bem-pattern插件，在保存时立刻报错：比如检测到.header .logo或user-card_avatar（漏了双下划线）就中断提交 - 在 React/Vue 中统一用工具函数生成类名，例如：
cn('button', { 'button--primary': isPrimary, 'button--loading': isLoading })，避免手拼字符串出错 - 组件 CSS 文件严格按块组织：
/components/button/Button.css只写.button、.button__icon、.button--disabled，禁止跨块引用 - 禁止在 JS 中操作原始类名：
el.classList.add('button__text')✅，el.className += ' button__text'❌（会破坏已有类名结构）
BEM 和 CSS Modules / scoped CSS 不是二选一，而是分工明确
BEM 解决的是「人眼可读性」和「协作边界」，CSS Modules 解决的是「编译期作用域」。即使开了 CSS Modules，如果类名还是叫 title、list，那在 DevTools 的 class 列表里依然难定位、易误读。
真实协作中容易踩的坑：
- 有人写
Button.module.css，里面却定义.root和.label—— 这等于白开了 CSS Modules，BEM 约束全失效 - 用
styled-components封装组件，但又在 HTML 里手动加card__body类——此时样式归属分裂：一部分由 JS 控制，一部分由外部 CSS 文件控制，后续抽离或替换组件时卡死 - 第三方库（如 Ant Design）已自带类名体系，强行套 BEM 包裹（如
my-button__inner）会增加冗余，且无法享受其主题变量体系
真正需要 BEM 的，是那些持续迭代超过 6 个月、多人协作、组件复用率高的核心业务模块。它不解决动态样式注入问题，也不替代 CSS-in-JS 的表达力，但它确保你删掉一个组件时，对应的所有样式都能被安全识别和移除——这点在 SPA 的长生命周期里，比任何炫技都重要。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
