bem严禁使用id选择器因其特异性过高（100）导致样式难以覆盖，且id违背组件唯一性原则，易在spa、ssr、微前端中引发冲突、dom异常、事件错乱及测试不稳定；替代方案为data属性或aria属性，js绑定优先用ref。
为什么BEM严禁使用#header这类ID选择器
因为ID选择器的CSS特异性（specificity）是100，远高于class（10），一旦用#nav写样式，后续几乎无法用常规class覆盖——哪怕加!important也治标不治本。BEM强调组件可复用，而ID天然违背“唯一性”前提：SPA里多个router-view可能同时渲染同名模块，id="user-card"必然冲突。
.UserCard和#user-card在真实项目中的表现差异
实际开发中，ID选择器会立刻暴露三个硬伤：
- 服务端渲染（SSR）或微前端场景下，多个子应用共存时
id重复触发HTML校验失败，控制台报DOMException: Failed to execute 'getElementById' on 'Document' - JavaScript用
document.getElementById()取元素，但BEM组件常需动态挂载/卸载，ID残留导致事件绑定错乱或内存泄漏 - 自动化测试（如Cypress）依赖稳定选择器，ID易被UI框架（React/Vue）动态生成或复用，而
.UserCard__avatar始终语义明确、定位精准
当必须标记“唯一容器”时，替代方案是什么
不用ID，不等于放弃语义化锚点。可行路径有且仅有两种：
- 对顶层Block加唯一data属性：
<div class="UserProfile" data-user-id="123">，CSS中用<code>[data-user-id]做轻量区分，特异性仅11，不影响覆盖链 - 用
aria-labelledby或aria-owns满足无障碍需求，它们不参与样式计算，也不破坏BEM的class-only原则 - 若真需JS强绑定，优先选
ref（Vue）或useRef（React），而非document.getElementById
团队落地BEM时最容易忽略的细节
很多团队写了.Button--primary却仍偷偷在HTML里留着id="submit-btn"，只因“方便调试”。但这个口子一开，新成员会默认ID可用，接着出现#Button--primary这种非法组合——BEM的class-only约束是原子级的，容不得半点妥协。真正省事的做法，是在ESLint插件stylelint-selector-bem-pattern里强制校验，把#字符直接拦在提交前。
