BEM命名本身不导致性能问题，瓶颈在于过度嵌套的选择器如.page-home .layout-main .header .header__logo--dark引发的逐级回溯匹配；应直接使用.card__title等独立选择器，避免祖先链过长，并通过工具拦截冗余嵌套。
移动端CSS选择器慢，真不是因为BEM名字长
性能瓶颈通常不在.header__logo--dark这种命名本身，而在于它被写在了过度嵌套的上下文中。比如.page-home .layout-main .header .header__logo--dark——浏览器要从右往左逐级回溯匹配，每多一层，就多一次节点遍历和计算。BEM只是帮你管住命名，不解决选择器执行逻辑。
避免「祖先链过长」：用scope或独立块替代嵌套
常见错误是把BEM当成“嵌套语法糖”，写成.card .card__title，其实.card__title本就可以独立存在。BEM的__表示“属于该块的元素”，不意味着它必须被父选择器包裹。
- ✅ 正确：直接用
.card__title，配合scoped（Vue）或:where()/:is()控制作用域 - ❌ 错误：写
.card > .card__title或.card .card__title，尤其在列表中大量复用时，重排重绘开销明显上升 - ⚠️ 注意：
!important和内联style会强制跳过CSSOM缓存，比选择器嵌套更伤性能
伪类和属性选择器在移动端容易触发重算
:hover在触摸设备上虽被降级为:active，但[data-status="loading"]这类属性选择器仍会迫使浏览器频繁检查DOM状态。iOS Safari对:nth-child()的优化也弱于桌面端。
- ✅ 推荐：用预设class切换状态，如
.button--loading，而非.button[data-loading] - ✅ 替代
:not(.disabled)：直接给可用态加.button--enabled，减少否定计算 - ⚠️ 注意：
*[class^="icon-"]这种通配符+属性前缀，在低端Android WebView里可能引发样式阻塞
BEM命名本身不影响渲染，但影响维护导致的隐性性能债
没人会因为.btn--primary比.primary-btn多两个字符而卡顿。真正拖慢迭代的是：当一个.modal__content被无意写成.modal .modal__content后，后续所有人复制粘贴都带上这层冗余，三个月后组件树里出现17处.modal .modal__content p a——这时问题已不在命名规范，而在选择器失控。
立即学习“前端免费学习笔记（深入）”；
- ✅ 用PostCSS插件
postcss-bem-linter或ESLint插件stylelint-selector-bem-pattern做CI拦截 - ✅ 在构建时用
cssnano开启reduceIdents和mergeLonghand，自动剔除无用嵌套 - ⚠️ 容易忽略：CSS-in-JS库（如Emotion）若用动态插值生成
css`${props => props.theme.primary}`，每次渲染都可能产生新规则，比BEM嵌套更难追踪
移动端CSS性能最常栽在“以为自己在优化命名，实际在纵容选择器膨胀”。BEM是约束工具，不是性能开关；能删掉的选择器，比再短的名字都有用。
