BEM与scoped不是二选一，而是分工协作：BEM管命名语义与模块归属，scoped管作用域边界；合用可防样式污染，但Block名须对齐文件名、动态类名须完整声明、穿透须用BEM容器限定。
BEM 和 scoped 不是二选一，而是解决不同问题的工具：BEM 管命名语义与模块归属，scoped 管作用域边界；混用能防污染，但错配就等于白加。
什么时候该用 BEM 而不是 scoped
当组件要被多个项目复用、或需被第三方直接引入（比如 npm 包），且你无法控制宿主环境的全局样式时，BEM 是刚需。scoped 生成的 data-v-xxx 属性在外部不可预测，别人没法覆盖或调试；而 .user-card__header 这种类名是稳定、可读、可约定的。
- 公共组件库（如自研的
ui-button）必须用 BEM，否则下游项目改个圆角都得靠!important或全局覆盖 - 需要 SEO 友好或服务端渲染（SSR）时，BEM 类名语义清晰，利于爬虫和无障碍识别；scoped 的哈希类名（如
_button_zkzc1_7）毫无信息量 - 团队协作中存在“非 Vue 开发者”（如后端写模板、设计师查 DevTools），BEM 类名一看就懂，
data-v-7a7a37b1对他们等于乱码
什么时候该用 scoped 而不是 BEM
业务组件内部快速迭代、样式逻辑简单、不对外暴露、也不需跨项目复用时，scoped 更轻量。它不强制你思考命名层级，写 .header 就完事，编译后自动隔离——但前提是，你接受它“只防外不防内”的事实。
- 页面级组件（如
DashboardPage.vue）用 scoped 足够，没必要硬套dashboard-page__main这种冗长命名 - 临时实验性组件、A/B 测试分支、或原型阶段，BEM 的约束反而拖慢节奏
- 团队尚未形成 BEM 共识，强行推行易导致
.user-card__header和.header并存，混乱翻倍
BEM + scoped 混用的关键红线
两者合用不是加个前缀就行，三处不守规则，整个隔离就失效：
-
Block名必须与组件文件名严格一致：文件叫UserCard.vue→ 类名只能是.user-card，不能是.card或.user__card - 动态类名必须完整声明：
:class="['user-card__item', isHover && 'user-card__item--hover']"，漏掉user-card__前缀，scoped 就不认这个类 - 穿透第三方组件（如
el-button）必须用 BEM 容器限定：.user-card__action-btn :deep(.el-button)，不能直接:deep(.el-button)，否则等于开了全局后门
为什么 CSS Modules 在中间态最稳
如果你既想要 BEM 的语义性，又想要 scoped 的隔离强度，css-modules 实际是更平衡的选择：它把 .user-card__header 编译成 _user-card__header_zkzc1_7，既保留了 BEM 结构，又彻底杜绝外部覆盖。
- 适合中大型业务系统：开发时写 BEM，打包后自动加 hash，兼顾可读性与安全性
- 避免 scoped 的权重陷阱：不会因为父组件也用了 scoped，就让子组件根节点多一个
data-v-xxx属性，导致样式意外叠加 - 缺点是调试时 DevTools 显示的是哈希类名，需配合 source map 或
localIdentName配置做可读性优化
真正难的不是选哪个方案，而是意识到：BEM 是命名纪律，scoped 是作用域机制，CSS Modules 是编译策略——它们解决的问题维度不同。一个组件里同时出现 .user-card__header[data-v-xxx] 和 ._user-card__header_zkzc1_7，说明团队还没对“谁负责什么”达成共识，这时候换方案不如先拉齐认知。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
