bem禁止标签选择器是因为其强绑定html结构，导致dom调整或组件复用时样式失效、误匹配、冲突及性能下降。
因为标签选择器会让样式强绑定 HTML 结构，一旦 DOM 调整或组件复用，样式立刻失效或误匹配——这不是写法问题，而是主动交出控制权。
button:hover 为什么比 .btn--hovered 更危险
表面看 button:hover 简洁直观，但它把样式锚定在 HTML 标签语义上：只要页面里出现任意 <button></button>，这条规则就生效。真实项目中这会立刻引发三类冲突：
- 第三方 UI 库（如 Ant Design）内部也用
button，你的button:hover可能覆盖它的默认交互，也可能被它反过来覆盖 - 同一个按钮在不同上下文需要不同悬停行为（比如表单提交按钮放大，弹窗关闭按钮变透明），
button:hover无法区分，只能靠更高权重或!important硬刚 - 自动化测试工具（Cypress / Playwright）靠类名定位，
button匹配全页所有按钮，定位不稳；而.btn--submit:hover精准唯一
.card h2 和 .card__title 的性能差距在哪
浏览器 CSS 匹配是「从右往左」进行的。.card h2 会先遍历所有 h2 元素，再逐个向上检查父级是否含 .card；而 .card__title 是单类名，直接哈希查找，几乎无开销。实测表明：
- 在低端安卓设备上，5 层嵌套选择器（如
.page .content .list li a）的 style recalc 时间比单类名慢 4 倍以上 - DevTools Performance 面板中 Recalculate Style 时间突然飙升，大概率就是这类选择器在拖后腿
- 哪怕只在局部写了
div p，也会污染全局匹配效率，影响所有后续规则
ul 和 .nav__list 的复用成本差在哪
ul 本身没有归属信息，无法区分导航菜单、评论列表、侧边栏链接——三者结构相同，但语义和样式需求完全不同。一旦强行共用 ul 样式，必然冲突或覆盖。更实际的问题是：
- 某天为无障碍升级把
<ul></ul>换成<div role="list">，所有基于 <code>ul的样式立即失效 - BEM 组件常被 SSR 或微前端动态注入，
ul无命名空间，极易被全局重置样式（如 normalize.css）意外干预 - 设计系统升级时，改
ul的list-style会影响所有场景，而.nav__list只管导航 -
article h2：看似结构清晰，实则把标题样式绑死在article内，挪到卡片或弹窗里就失效 -
form input[type="text"]：输入框类型随框架变化（React 可能用原生<input>，Vue 可能封装为自定义组件），且无法表达“搜索输入框”还是“用户名输入框” -
svg path：图标路径样式应归属.icon--search，而非依赖 SVG 结构，否则换用 iconfont 或<img>就崩
哪些“语义化”理由其实是认知偏差
开发者常以“HTML 语义化”为由保留标签选择器，但多数混淆了 HTML 语义与 CSS 归属：
BEM 不禁止你写 button，但它要求你意识到：只要用了，这个样式就不再属于某个组件，而属于整个 HTML 规范——而这正是大型项目样式失控的起点。真正难的不是起对名字，而是每次敲下 button 时，是否清楚自己正在交出哪部分控制权。
