子选择器>比后代选择器快，因浏览器从右往左匹配时，>限定每步只查直接父节点，路径更短、无需遍历整棵子树；而后代选择器需向上回溯多层祖先链，DOM越深、节点越多，性能损耗越明显。
子选择器 > 为什么比后代选择器快
浏览器匹配 CSS 选择器时，是从右往左执行的。比如 .nav ul li a，它会先找所有 a 元素，再逐层向上检查父节点是否为 li、再是否为 ul、再是否带 .nav 类——这个“向上爬”的链越长，开销越大。
而 .nav > ul > li > a 把每一步都限定在 immediate children 范围内：只查 a 的直接父节点是不是 li，再查该 li 的直接父节点是不是 ul……不遍历整棵子树，路径更短，回溯更少。
实际影响最明显的场景包括：
-
ul li→ 改成ul > li：菜单项多、嵌套深时，避免对二级ul里的li做无效回溯 -
.card p→ 改成.card > p：卡片内若含富文本或子组件，大量p节点不用再逐个向上爬 N 层 -
.menu a→ 改成.menu > a：防止弹窗、工具栏等同名 class 的a被拉进匹配队列
性能差异在什么情况下才真正明显
日常小页面几乎感知不到区别，但以下三类情况会暴露差异：
立即学习“前端免费学习笔记（深入）”；
- DOM 节点数超 5000，且存在高频重排/重绘（如滚动加载列表、实时图表）
- 选择器被用于
:hover、@keyframes或 JS 动态切换 class 的热区 - 使用了长链组合，如
.sidebar .content > ul > li > a这类高特异性写法
此时 .sidebar .content ul li a 可能触发多次完整子树遍历，而加 > 后能减少 30%～60% 的匹配耗时（实测 Chrome DevTools 的 Rendering 面板可验证）。
别为了性能硬套 >，结构契约才是代价
子选择器快，是因为它把“结构脆弱性”显性化了。容易踩的坑包括：
- JS 动态插入节点时，用
document.body.appendChild(el)，.modal > .content就会失效——el并非.modal的直接子节点 - Vue 的
v-if或 React 的Fragment可能悄悄插入 wrapper 元素，让父子关系变成“爷孙” -
div > p > span这种三层链，中间插一个<em></em>或注释节点就完全断链，而div p span仍能命中
真正容易被忽略的，是性能优化和 HTML 结构强绑定：你得到更快的匹配，也同时承担了 DOM 必须严格对齐的风险。这不是缺陷，而是提前暴露问题的信号。
