大型前端项目不用bem不是“容易出问题”，而是必然失控：改一个padding会导致多页面样式错乱；其性能优势源于单类名一次哈希查找，而非命名长短；bem通过归属+角色+状态三重语义防跨模块污染，但需工具链（如stylelint-selector-bem-pattern）强制校验落地。
大型前端项目不用 BEM，不是“容易出问题”，而是改一个 padding 就会让三个不相关页面的按钮错位、弹窗遮罩消失、响应式断点集体失效——这不是偶发 bug，是结构松动后的必然连锁反应。
为什么单类名选择器在浏览器里真更快
BEM 的性能优势不来自名字长短，而在于浏览器匹配路径：.user-card__avatar--loading 是单类名，浏览器查 class 哈希表一次命中；.user-card .avatar 则要先找所有 .avatar 元素，再逐层向上检查父级是否为 .user-card，DOM 越深越慢。
实操建议：
- DevTools → Elements → Computed → Styles 面板里直接看：有空格就是嵌套选择器，是潜在性能隐患
- Sass 中写
.user-card { &__avatar { } }安全；但写.user-card { & .user-card__badge { } }就会编译出带空格的选择器，破坏隔离性 - 构建后用
grep -r "\.[a-z]\+ \.[a-z]" dist/快速揪出残留的空格选择器
为什么 BEM 能防样式“跨模块污染”
没 BEM 时，.btn 这种类名等于没定义归属：Billing 子应用和 UserManagement 子应用都引入同一份按钮样式，又各自加了 .btn { padding: 4px }，浏览器只认最后加载的那条，没人能说清谁赢谁输。
BEM 把归属直接塞进名字：checkout-form__submit-btn--disabled 明确属于 checkout-form 模块，且带状态；user-profile__avatar--xs 不会和任何其他 avatar 冲突。
常见破功点：
- 伪 BEM：HTML 写
class="user-card user-card--loading"，但 CSS 只定义了.user-card--loading，漏掉基础块样式，删 modifier 整个组件就崩 - 跨 Block 的 Element：把
user-card__avatar放到非user-card容器里，或写成user-card__header__title（BEM 不允许 Element 嵌套 Element） - 修饰符滥用：写
button--width-200px这类含具体值的类名，换单位或加媒体查询就得新增一堆类
为什么工具链不“焊死”BEM 规则，规范一天就形同虚设
光靠文档和口头约定没法落地。手滑一次，比如在 SCSS 里写了 & a { color: blue; }，就等于注入了全局 a 样式，和 BEM 无关。
必须配置 stylelint-selector-bem-pattern 插件，规则设为 { "componentName": "[a-z][a-zA-Z0-9]+", "styleType": "bem" }，自动拦截 .card .title、.btn-primary 等非 BEM 写法。
CI 流程中跑 npx stylelint "**/*.{css,scss}"，失败则阻断合并。
禁止在 JS 中拼接字符串：className={`card__body ${isCollapsed ? 'card__body--collapsed' : ''}`} 改为用 cn('card__body', { 'card__body--collapsed': isCollapsed })（配合 clsx）。
真正难的不是写出 block__element--modifier，而是让团队在加一个 tooltip 时，本能地新建 /components/tooltip/，而不是往 modal.css 里塞 .modal__tooltip——这需要目录约束、CI 检查、以及最初几个模块的示范性实现。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
