浏览器从右向左匹配CSS选择器，先找最右元素再逐层向上验证父级，层级超三层时性能急剧下降；ID和类选择器支持哈希查找，通配符和属性选择器应避免，状态类优于复杂选择器。
浏览器从右向左匹配选择器，别被表象骗了
很多人以为写 .nav .list .item a 是“精准定位”，实际浏览器先找所有 a 标签，再逐层往上查父级是否含 .item、.list、.nav。DOM 节点多时，这个过程会爆炸式增长。
- 嵌套每多一层，匹配成本不是线性增加，而是接近平方级上升
-
div.header ul.nav li a:hover这类写法在 1000+ 节点页面里可能拖慢样式计算 20ms+（实测常见） - ID 和类选择器是唯二能哈希查找的类型；
#header比.header略快，但差别不大，优先用语义类名更可持续
三层以内是硬门槛，不是建议
Chrome DevTools 的 Rendering 面板里，“Style” 阶段耗时高，八成问题出在选择器层级超标。所谓“三层”，指从右往左数的有效选择器片段数，比如 .card .title span 是三层，.card > .content .text em 是四层（em → .text → .content → .card）。
- 把
article section header h1改成.article-header-title，样式计算时间常能砍掉 40%+ - Bootstrap-Datepicker 优化案例中，
.datepicker table tr td.day（5层）改为.dp-day后，单元素匹配耗时从 18ms 降至 2.3ms - 不要为了“结构清晰”牺牲性能——DOM 结构本就该为样式服务，而不是反过来
通配符和属性选择器，能不用就不用
* 和 [type="submit"] 看似方便，但它们强制浏览器遍历全部节点或扫描每个元素的属性，开销远高于类选择器。
-
* { box-sizing: border-box }应拆成html, body, div, span, article, ...（或直接用 reset.css 的显式列表） -
input[disabled]可接受，但div[data-id^="user-"]这种带正则的属性选择器会触发全量属性解析，务必避免 - 表单控件统一加语义类，如
.form-input-disabled，比靠属性匹配稳定且快
动态状态别靠复杂选择器推导
用 JS 切换 .is-open、.is-loading 这类状态类，比写 .modal.open .overlay 或 .btn:not(:disabled):hover 更可控、更易测、也更快。
立即学习“前端免费学习笔记（深入）”；
-
:not()、:nth-child()等伪类需运行时计算，匹配成本高；.btn--loading是静态类，零计算开销 - 父子联动样式（如
.parent.expanded .child）容易因中间节点 class 变更失效，改成.child--expanded更健壮 - 动画场景下，
.animating类配合transform+will-change，比依赖 DOM 层级关系更可靠
真正卡顿的从来不是“写不出效果”，而是浏览器在毫秒级内反复做无谓的树遍历。选对类名，等于提前告诉浏览器：“就这儿，别找了。”
