css选择器从右往左匹配，子选择器（>）限定直接父子关系，路径更短、性能更高；但要求html结构严格，动态插入或框架wrapper易破坏契约。
浏览器匹配是从右往左的，子选择器路径更短
CSS 选择器不是从左往右“找儿子”，而是从右往左“验家谱”。写 .nav ul li a，浏览器先抓所有 a 元素，再逐个向上查：父节点是不是 li？再往上是不是 ul？再往上是不是带 .nav 的元素？DOM 越深、节点越多，回溯链越长。
而 .nav > ul > li > a 的匹配路径被 > 锁死：只检查每个 a 的**直接父节点是否为 li**，再检查该 li 的直接父节点是否为 ul，依此类推。每一步都限定在 immediate children 范围内，不遍历整棵子树。
高频场景下性能差异最明显
以下三类写法改用 > 后，重排/重绘压力下降最可观：
-
ul li→ 改成ul > li：菜单项数量多、嵌套深时，避免对二级ul里的li做无效回溯 -
.card p→ 改成.card > p：卡片内若含富文本或子组件，大量p节点不用再逐个向上爬 N 层 -
.menu a→ 改成.menu > a或.menu > ul > li > a：防止弹窗、工具栏等同名 class 的a被拉进匹配队列
但性能提升不是无代价的
子选择器快，是因为它把“结构脆弱性”显性化了。容易踩的坑包括：
- JS 动态插入节点时，如果用
document.body.appendChild(el)，.modal > .content就会失效——el并非.modal的直接子节点 - Vue 的
v-if或 React 的Fragment可能悄悄插入 wrapper 元素，让原本的父子关系变成“爷孙” -
div > p > span这种三层链，中间插一个em或注释节点就完全断链，而div p span仍能命中
真正容易被忽略的，是性能优化和结构契约绑在一起：你得到更快的匹配，也同时承担了 HTML 必须严格对齐的风险。这不是缺陷，而是提前暴露问题的信号。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
