bem类名能直接对应组件文件结构，因其强制组件目录名、文件名、css块名三者一致，如/user-card/目录下usercard.module.css仅含.user-card及.user-card__avatar，且禁止嵌套选择器确保样式不随dom结构变化失效。
BEM 不是“让模块化变得可能”的工具，而是把模块化这件事从构建时提前到写代码第一行就落地的约束机制——它不依赖 Webpack 或 Vite，也不靠 JS 运行时生成类名，纯靠命名本身携带语义和边界。
为什么 BEM 类名能直接对应组件文件结构
BEM 的 .user-card 几乎就是 UserCard.vue 或 UserCard.tsx 的直译。这种映射不是巧合，是设计使然：组件目录名、文件名、CSS 块名三者一致，比如 /components/user-card/UserCard.module.css 里只出现 .user-card 和 .user-card__avatar。
常见错误现象：.card .header 这类嵌套选择器会让样式依赖 DOM 层级，一旦父组件被重构或抽离成 npm 包，样式立刻失效；而 .user-card__header 天然绑定宿主块，不随 DOM 结构变化漂移。
- 元素（
__）必须是块的直接子结构角色，不能嵌套：✅.dialog__title，❌.dialog__header__title - 修饰符（
--）只描述业务状态，不表达样式细节：✅.button--disabled，❌.button--bg-blue-500 - 构建工具（如 stylelint-selector-bem-pattern）可强制校验类名是否匹配目录名，CI 阶段就能拦截
.ui-input__field出现在user-card.css中这类问题
为什么 BEM 在无 JS 环境下仍能保证样式隔离
微前端子应用或 Java/PHP 模板直出 HTML 时，JS 还没执行，CSS-in-JS 或 CSS Modules 的哈希类名根本没机会生成——此时 BEM 类名就是唯一契约。
使用场景包括 SSR 页面首屏渲染、后端模板工程师维护静态页、甚至邮件模板中的内联 CSS。
-
search-form__input和checkout-form__input即使共用同一份 CSS 文件，也不会互相覆盖 - 后端人员能读懂
user-profile__avatar--xs含义，并直接追溯到/components/user-profile/目录 - 禁止嵌套选择器意味着：即使 DOM 被其他子应用意外插入 wrapper 元素，
.user-card__avatar依然生效
为什么 BEM + CSS Modules 不是重复劳动
CSS Modules 解决的是“全局污染”，BEM 解决的是“语义混乱”——前者把 .button 编译成 Button_button_abc123，后者告诉你这个 button 是哪个业务模块里的。
没有 BEM 时，styles.container 和 styles.content 谁包谁？别人读代码得猜；有 BEM 后，product-card__body 一眼可知它是 product-card 的直属内容区。
-
CSS Modules的 tree-shaking 安全前提，是类名不依赖 DOM 层级；BEM 扁平结构（无.a .b）正好满足 - 修饰符如
--disabled绑定具体 Block，比泛用的is-disabled更可靠：它明确表达“这个按钮处于禁用态”，而非一个可能被误复用的状态标记 - 组件库导出 class 前缀必须可配置（如
prefix="ui"），但内部结构不变：${prefix}-button__icon，方便下游换肤或降级
真正容易被忽略的，是 BEM 要求你为每个视觉单元都明确回答三个问题：“它是不是独立块？”“它是不是某块的固有部分？”——答案模糊的地方，就是未来样式泄漏的起点。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
