后代选择器匹配从右向左：先定位所有最右元素（如.b），再逐个向上遍历祖先链验证是否含.a；DOM越深、节点越多，回溯路径越长、耗时呈指数增长，而子选择器>仅查直接子节点，路径固定、性能更优。
后代选择器匹配过程是“从右往左遍历整棵子树”
浏览器解析 .a .b 时，并不是从 .a 开始往下找 .b，而是先定位所有带 .b 的元素，再逐个向上检查其祖先链里有没有 .a。DOM 越深、.b 节点越多，回溯路径就越长——尤其是当页面有 2000+ 行表格或大量动态插入内容时，Recalculate Style 单次耗时可能飙到 8–12ms。
常见错误现象：table tr td .cell-value 在大数据表格中卡顿明显；换成 .cell-value 后压到 0.3ms 左右。
- 关键选择器（最右边那个）决定初始筛选成本：
.b是类名，O(1) 查哈希表；但若写成div p，就得遍历全部p元素再向上查父级 - DOM 深度超 10 层时，每多一层后代嵌套，匹配开销可能翻倍
- 滚动、hover 或 JS 触发 class 切换时，这种开销会高频复现，直接导致掉帧
子选择器 > 只查第一层子节点，跳过深层遍历
.a > .b 的匹配逻辑简单得多：找到所有 .a 元素，只检查它们的 immediate children 是否为 .b。不往上追溯祖先，也不往下钻进孙子节点——这使得它在长列表、动画敏感或移动端低端设备上更可控。
典型误用：.nav > ul > li > a 看似严谨，但一旦 HTML 插入中间层（比如加了 <details></details>），整个链就断掉；而它的性能优势恰恰来自这种“短路径”约束。
立即学习“前端免费学习笔记（深入）”；
- 不需要维护祖先链，避免了向上遍历的 CPU 开销
- 在频繁重排场景（如虚拟滚动、实时搜索高亮）中，比等效后代选择器稳定 3–5 倍
- 兼容性无负担：IE7+ 全支持，性能差异与浏览器版本无关，只取决于 DOM 结构和节点数量
为什么日常开发几乎感觉不到这个“微小差异”？
因为大多数页面 DOM 节点少于 500 个，且样式规则简单。这时浏览器优化足够强，.card p 和 .card > p 的匹配耗时差不到 0.05ms，DevTools 里都难拉出明显波动。
但一旦进入以下任一场景，差异就会暴露：
- 后台系统表格行数 ≥ 1000，且每行含多个带类名的嵌套元素
- 富文本区域使用 CMS 输出 HTML，结构不可控但样式需兜底（此时必须用空格，但得接受代价）
- 组件被反复挂载/卸载（如 React 中
key频繁变化），触发批量 style recalc
真正容易被忽略的点是：性能问题往往不出现在写 CSS 的那一刻，而出现在半年后数据量涨了 10 倍、没人记得当初为什么选了 section article p 而不是 .article-content p。
