子选择器能提升性能，因浏览器从右向左匹配时，> 限定直接父子关系，减少回溯路径；高频场景如 ul li、.card p、.menu a 换用 > 收益最大，但需确保 HTML 结构严格对齐。
子选择器为什么能提升性能
浏览器匹配 CSS 选择器时，是从右往左执行的。.nav ul li a 这种后代写法，会让浏览器先找所有 a 元素，再逐层向上检查是否在 li、ul、.nav 内部——DOM 越深、节点越多，回溯路径就越长。而 .nav > ul > li > a 因为用 > 锁死了父子层级关系，浏览器只需确认每个 a 的父节点是 li、且该 li 的父节点是 ul、再上一级是 .nav，路径更短，验证步骤更少。
哪些场景换用 > 改动最小但收益最大
不是所有后代选择器都该硬替换成子选择器，重点盯住三类高频高风险写法：
-
ul li→ 改成ul > li：菜单、列表项样式最常误染二级下拉项 -
.card p→ 改成.card > p：避免卡片内嵌富文本或子组件里的p被统一改行高 -
.menu a→ 改成.menu > a或.menu > ul > li > a：防止弹窗、工具栏里同名 class 的a被意外覆盖
换完之后发现样式丢了？先查这三点
子选择器失效往往不是语法错，而是 HTML 结构没对齐：
- JS 动态插入的节点（比如 modal、tooltip）可能没直接 append 到目标父容器，而是通过
documentFragment或临时 wrapper 插入，导致>断链 - 中间某层 DOM 是自闭合标签（如
<br>
）或注释节点，会破坏“直接子”关系 - 用了
v-if/ngIf等条件渲染，父元素存在但子元素未挂载，>就找不到目标节点
别只盯着 >，配合 :not() 才真正防误伤
单独用 > 只解决层级穿透问题，但无法排除禁用、隐藏等状态节点。真正干净的组合是：
立即学习“前端免费学习笔记（深入）”；
.menu > li:not(.disabled) > a { cursor: pointer; }
这里 :not(.disabled) 的作用域被 > 限定在第一层 li 上，不会误判内嵌子菜单里的 .disabled 项。换成 .menu li:not(.disabled) a，就又掉回后代陷阱里了。
真正容易被忽略的是：子选择器不是性能银弹，它把“结构脆弱性”显性化了——一旦 HTML 嵌套微调，样式立刻失效。这不是缺陷，而是提前暴露契约断裂的信号。
