BEM本身不自动改善设计系统可维护性，它只在被严格约束、配合工具链和团队共识时，才能把“谁改了什么样式导致哪块UI崩了”从猜谜变成可定位、可追溯、可自动化拦截的工程问题。
直接说结论：BEM 本身不自动改善设计系统可维护性，它只在被严格约束、配合工具链和团队共识时，才能把“谁改了什么样式导致哪块 UI 崩了”这个问题从猜谜变成可定位、可追溯、可自动化拦截的工程问题。
为什么 .button 在设计系统里是危险信号
设计系统里每个组件都可能被多个业务线复用。.button 这种裸名类没有归属声明，一旦 marketing-button.css 和 admin-button.css 都定义了它，构建后谁生效取决于打包顺序或 CSS 加载时机——浏览器不报错，UI 却在灰度环境突然变样。
- 真实翻车场景：
.input在表单模块里设了border-radius: 4px，但后台系统的.input要求直角；没人敢删，只能加!important，最后所有输入框圆角逻辑全靠权重博弈 - BEM 强制写成
.form-field__input和.admin-table__cell-input，光看类名就知道样式边界在哪，冲突不再隐性发生 - 关键点：Block 名必须对应设计系统中一个可交付的原子组件（如
text-field），不能是泛义词（如field）或位置词（如top-input）
button--primary 单独使用为何破坏设计系统契约
设计系统不是样式集合，而是语义契约。button--primary 脱离 button 宿主存在，就等于把“主按钮状态”抽象成全局概念，结果是营销页的 button--primary 和弹窗里的 button--primary 共享同一份 CSS 规则，但它们的 padding、font-size、hover 行为本应由各自上下文决定。
- 合法写法：
class="button button--primary"或class="button button__icon button--primary" - 非法写法：
class="button--primary"（语义断裂）、class="cta-button--primary"（新 Block 未注册进设计系统文档） - 工具链必须拦截：stylelint-selector-bem-pattern 配置中需禁用
selector-bem-pattern的自动修复，只允许报错；否则 CI 会把.primary-btn自动转成.primary-btn__btn，彻底毁掉语义
Element 嵌套层级错误如何让设计系统“悄悄失效”
设计系统依赖结构稳定性。BEM 规定 Element 只能直属于 Block，禁止 .card__header__title 这类三层嵌套——因为一旦某天卡片 Header 被抽成独立组件，.card__header 就不再是容器，.card__header__title 的样式立即失效，但开发者在 DevTools 里看到 class 存在，第一反应是“CSS 没加载”，而不是“命名结构已过期”。
立即学习“前端免费学习笔记（深入）”；
- 正确结构：
<article class="card"><h2 class="card__title">，哪怕标题实际在<header>内，也必须保持card__title直属card - 常见误判：以为 “HTML 结构嵌套深，类名就得跟着深”，结果写出
.user-profile__section__avatar，而设计系统规范里avatar是独立 Block，应直接引用.avatar - 检查手段：PostCSS 插件
postcss-bem-linter可扫描出所有含三个及以上下划线的类名，并标记为高危
最常被忽略的是：BEM 类名不是写完就结束，它必须和设计系统的组件文档、Figma 组件命名、Storybook stories 名称完全对齐。比如 Figma 里叫 Text Field / Error State，代码里就必须是 .text-field__input--error，差一个连字符，整个链路就断了——没人能靠搜索快速确认“这个 error 状态在设计稿里长什么样”。
