bem 嵌套过深会引发选择器权重失控、可维护性下降、类名匹配性能损耗及动态拼接易出错等问题，应按语义独立性拆分 block，严格区分 --modifier（静态变体）与 is-*（运行时状态），并配套工具链规范保障一致性。
为什么 BEM 的 block__element--modifier 不能嵌套太深
因为 CSS 选择器权重和可维护性会快速失控。实际项目里，写到 header__nav__item__link--active 这种层级，不仅样式难覆盖，连开发者自己都记不清哪一层该加哪个 modifier。
- 浏览器解析时，每多一个
__就多一次类名匹配，虽单次影响小，但组件复用多时累积明显 - Vue/React 中动态拼接类名（如
class="card__body card__body--expanded"）容易漏掉中间层级，导致样式断裂 - BEM 原意是“一个 block 管理自己的结构”，
card不该知道card__body里还有没有__title或__footer—— 那该是card__title和card__footer
如何正确拆分复杂 UI 成 BEM block
不是看视觉区块大小，而是看是否具备独立语义、可复用、能脱离上下文存在。比如“带搜索的用户列表”不是单个 block，它至少是 user-list + search-bar 两个 block。
- 检查能否单独写 Storybook 演示：如果去掉父容器就渲染异常，说明它不该是 element，而该是独立 block
- 避免
page-header__logo-link--dark这种写法；logo-link在多数项目中是通用组件，应提为logo-linkblock，用logo-link--dark控制变体 - 第三方组件（如
el-button）不要强行套 BEM 类名，用 wrapper block 包裹并定义其在当前上下文的角色，例如form-actions__submit-btn
is-* 和 --* modifier 的实际取舍
二者语义不同：--* 描述状态或外观变体（button--primary），is-* 表达运行时状态（is-disabled、is-open）。混用会导致 JS 控制混乱、CSS 覆盖冲突。
- 静态配置（主题、尺寸、风格）用
--*：它们在构建时确定，不随交互变化 - JS 动态控制的状态必须用
is-*：否则 Vue 的:class或 React 的className切换会和预设类名打架 - 不要写
button--primary is-disabled—— 应该有button--primary button--disabled或统一用is-disabled并靠 CSS 重置所有变体下的禁用样式
PostCSS + BEM 工具链里最容易被忽略的兼容点
很多团队用 postcss-bem 或 postcss-nested 自动展开嵌套写法，但没意识到：这些插件默认不处理 @apply（Tailwind 场景）或 CSS-in-JS 中的字符串拼接。
- Webpack/Vite 的
css-loader开启modules: { localIdentName: '[name]__[local]___[hash:base64:5]' }后，BEM 类名会被哈希，破坏人工约定的命名可读性 —— 若需调试，得关掉 CSS Modules 或只对非 BEM 文件启用 - 使用
stylelint-selector-bem-pattern时，规则对 SCSS 的&__element支持良好，但对 CSS-in-JS 的模板字符串（如className={`${prefix}__item`}）完全无感知 - 设计系统交付给其他团队时，别只给 CSS 文件 —— 必须同步提供 BEM 命名 JSON Schema 或 ESLint 规则，否则下游很容易写出
modal__close-btn（正确应为modal__close-button）
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
