必须用bem类名，因其将模块归属、角色和状态编码进类名，解决shadow dom中语义模糊、调试困难、协作低效问题，而非仅防样式污染。
Web Components 的 Shadow DOM 确实提供了样式封装，但 BEM 依然关键——它不是为“防污染”而存在，而是为“人能读懂、机器能校验、团队能协作”服务。
Shadow DOM 并不自动解决语义混乱
即使样式被隔离，class="title" 或 class="btn-active" 这类命名在组件内部依然模糊：它属于哪个模块？是标题还是副标题？是按钮自身状态，还是其图标状态？BEM 把上下文直接编码进名字里，比如 card__title 和 button__icon--loading，一眼可知归属与角色。
- Shadow DOM 隔离的是作用域，不是语义。没 BEM，
.content在<user-card></user-card>和<post-list></post-list>里长得一样，但含义完全不同 - 调试时 DevTools 里看到
user-card__avatar--large，不用点开模板就能判断这是用户卡片的头像变体，而不是某个全局avatar类的意外复用 - 构建产物中 grep
user-card__能精准定位所有相关样式和 HTML 片段，而class="avatar"可能散落在十几个组件里
第三方集成与 SSR 场景下 BEM 仍是事实标准
很多 Web Components 库（如 Shoelace、Ionic）输出的 class 名默认遵循 BEM 或类似模式；服务端渲染（SSR）或静态生成时，Shadow DOM 尚未激活，外部 CSS 仍需靠类名匹配——这时 dialog--open 比 is-open 更安全、更可预测。
PigX UI Pro 前端开发指南 - Vue 3 + TypeScript + Element Plus。当用户提到 PigX UI、PigX 前端、lgb-mgui 项目、Vue 3 企业级后台开发、Element Plus 后台开发时使用此技能。
- 当
<sl-dialog open></sl-dialog>渲染为 HTML 字符串时，它依赖sl-dialog--open触发过渡动画，而非 JS 注入的临时类 - 下游项目用 CSS Modules 或 Tailwind 封装 Web Components 时，常需提取并重映射内部类名：
styles['card__header']比styles.header更不易冲突 - 部分构建工具（如 Lit + esbuild）对
:host(.card--featured)的处理不如纯 class 稳定，BEM 类名提供 fallback 兜底能力
BEM 是跨技术栈的通用契约，不是 CSS 工具链附属品
你在写一个 Lit 组件，同事用 Stencil 写另一个，设计系统文档里写的“按钮禁用态应加 button--disabled”，这个约定不依赖框架、不依赖构建器，只靠命名本身传递意图。
- UI 设计师交付的标注稿里写 “
input__field--error”，前端无需问“这是哪个 input？”“error 是修饰整个块还是仅 field？” - 自动化测试脚本用
page.locator('.form__submit--loading')定位，比page.locator('button[aria-busy="true"]')更直白、更少依赖运行时属性 - Code Review 时发现
card__footer__action，立刻知道违反了 BEM（Element 不得嵌套 Element），哪怕这个组件完全跑在 Shadow DOM 里
真正容易被忽略的点是：BEM 在 Web Components 里不用于“绕过 Shadow DOM”，而是作为跨层通信的语言——它让 HTML 结构、CSS 逻辑、JS 行为、测试断言、设计文档，全都共享同一套最小语义单位。一旦删掉双下划线和双短横，你就得靠注释、靠文档、靠人肉对齐，而这些恰恰是规模化协作中最先失效的部分。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
