低端移动设备因CPU弱、渲染管线简陋，CSS选择器匹配开销被显著放大，如四层嵌套选择器.page .section .card .card__title在Redmi Note 8上单次匹配耗时0.5–2ms，50个同类卡片可拖慢50–100ms；div ul li a比.nav-link慢3倍；BEM命名本身不慢，但冗余上下文（如.header .header__logo--dark）会强制逐级验证；属性选择器（如[data-status="loading"]）和伪类（如:not(.disabled)、:nth-child(2n)）在低端机上无法缓存结果，解析极慢；推荐用预设class（如.button--loading）替代动态选择器，并注意性能问题常隐于Layout阶段而非Rendering面板。
因为低端移动设备的CPU弱、渲染管线简陋、CSSOM构建慢，选择器匹配开销会被明显放大——不是“有点慢”，而是可能直接卡住首屏渲染。
浏览器从右往左匹配时，嵌套越深越容易卡住
比如 .page .section .card .card__title 这种四层选择器，浏览器会先找所有 .card__title，再逐级向上验证父级是否存在。在低端 Android WebView 或旧版 Chrome for Android 上，一次匹配可能耗时 0.5–2ms；如果页面有 50 个同类卡片，光这一条规则就可能拖慢 50–100ms，足够让用户感知到“顿一下”。
- 实测中，
div ul li a比.nav-link平均多花 3 倍匹配时间（测试机型：Redmi Note 8，Android 10，Chrome 87） - 超过三层嵌套的选择器，在低端机上触发重排的概率显著上升，尤其配合
transform或opacity动画时 - 不要依赖 “现代浏览器都优化好了”——很多预装浏览器（如华为浏览器、小米浏览器）底层仍是旧版 WebKit 或定制 Chromium，对选择器优化不敏感
BEM命名本身不慢，但写法错就会雪上加霜
很多人以为 .header__logo--dark 这种长名字是性能瓶颈，其实不是。真正出问题的是把它塞进冗余上下文里，比如 .header .header__logo--dark ——这等于强制浏览器每次都要确认 .header__logo--dark 确实挂在 .header 下面。
- ✅ 正确姿势：
.header__logo--dark单独使用，靠 BEM 的语义隔离作用域 - ❌ 错误复用：
.card .card__title出现在列表循环中，每个.card都要重新做一次祖先链验证 - ⚠️ 特别注意：Vue 的
<style scoped>或 React 的 CSS Modules 生成的属性选择器（如[data-v-abc123]）会叠加在原有选择器上，实际输出可能是.card[data-v-abc123] .card__title[data-v-abc123]，相当于双倍嵌套
属性选择器和伪类在移动端更危险
[data-status="loading"] 或 :not(.disabled) 看似简洁，但在低端设备上，浏览器必须实时检查每个匹配元素的 DOM 属性或状态，无法缓存结果。
立即学习“前端免费学习笔记（深入）”；
-
:hover在触摸设备上虽被降级为:active，但某些安卓 WebView 仍会保留 hover 状态监听逻辑，白耗 CPU -
:nth-child(2n)在 iOS Safari 14 以下版本中解析极慢，比等效的.item--even多 4–6 倍耗时 - 推荐提前计算好状态 class：用
.button--loading替代.button[data-loading]，用.list-item--first替代:first-child
最容易被忽略的点是：选择器性能问题往往不出现在 DevTools 的 “Rendering” 面板里，而藏在 “Layout” 阶段的隐式触发中——比如一个看似静态的 .sidebar .sidebar__item a，只要旁边 JS 改了某个父级的 display，整条链就会重跑匹配。这时候你得看的是“强制同步布局”的调用栈，而不是单纯盯着 FPS 数字。
