bem本身不提升可维护性，关键在于强制显式归属与切断隐式依赖；泛化类名如.btn因全局作用域和隐式复用导致样式冲突，应优先重构被多处复用且命名泛化的模块，通过语义映射添加唯一block前缀并禁用后代选择器。
直接上 BEM 不会自动提高可维护性；真正起作用的是「强制显式归属」+「切断隐式依赖」。旧项目里改一个 .btn 导致三处 UI 崩溃，问题不在命名长度，而在没人知道这个类属于谁、能不能动、改了会影响哪几个页面。
为什么 .btn 这种泛化类名上线后突然崩了
CSS 是全局作用域，浏览器只认字符串匹配，不认“上下文”。你写的 .btn 可能同时命中登录页提交按钮、弹窗取消按钮、表格操作列导出按钮——谁生效，取决于加载顺序、!important 数量、选择器权重，甚至 Webpack 分包 chunk ID 的哈希值。
- DevTools 里看到多个
.btn规则叠加，权重相同，最终生效的是最后加载的那个——而这个“最后”在构建产物中可能随构建时间或依赖版本变化 - 删掉一段旧 CSS，首页轮播图的
.next按钮却消失了，因为它复用了另一个模块的.btn样式 - 加
!important覆盖？只会让下一个人更难收场
怎样识别该优先重构的模块（不是从 .btn 开始）
别全局搜索泛化类名。真正拖慢迭代的，是那些你改完一个地方、第二天收到三张样式 bug 工单的模块：
- 被至少两个以上页面或组件复用，但类名泛化（如
.list、.header） - 开发者常靠 DOM 层级强压（如
.page .content .item a）或加!important才能覆盖 - 上线后偶发「某个按钮变宽」「弹窗对齐错乱」，查半天发现是另一个模块的
.active泄露
这类模块就是迁移起点。先给它加 wrapper class，比如把旧 <div class="nav"></div> 改成 <nav class="main-nav"></nav>，后续所有新增子元素都走 main-nav__item、main-nav__toggle。
老 HTML 怎么不动结构就套上 BEM 类名
很多旧项目 DOM 层级深、嵌套乱，硬要按 BEM 拆元素会牵一发而动全身。更务实的做法是「语义映射」而非「结构重排」：
- 原 HTML：
<div class="form"><input></div> - 不改结构，只加归属：
<div class="form-item"><input class="form-item__input"></div> - 对应 CSS：删除所有孤立的
.input、.error规则，只保留.form-item__input和.form-item__error--visible - 禁止写
.form-item .input这类后代选择器——它等于主动放弃 BEM 的隔离能力
BEM 不是加前缀，是让类名自带上下文
user-card__avatar--large 这种写法的价值，不是“看起来规范”，而是你扫一眼就能确认：它属于 user-card 模块，是头像元素，且处于大尺寸状态。不用翻 HTML 结构、不用查 CSS 文件路径、不用猜设计稿意图。
-
block名必须唯一且语义明确：product-card✅，card❌（别人写.card__title时根本不知道你在哪个业务域） -
element必须是block的直接子语义：search-bar__input✅，search-bar__icon__close❌（应拆成search-bar__icon+icon--close或新 block） -
modifier只表达静态变体或视觉状态：button--primary✅，button--loading❌（这是 JS 状态，该用is-loading或数据驱动）
真正容易被忽略的点：BEM 不是写完就结束的事——它要求每个元素只挂一个 BEM class，禁止单独使用 modifier（button--primary 必须和 button 同时存在），也禁用单下划线（user_name 会导致工具链无法解析层级）。这些约束一旦松动，整个架构就退化回老样子。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
