CSS选择器从右往左匹配，子选择器（>）限定直接父子关系，路径更短、性能更高；但要求HTML结构严格，动态插入或框架wrapper易破坏契约。

浏览器匹配是从右往左的，子选择器路径更短

CSS 选择器不是从左往右“找儿子”，而是从右往左“验家谱”。写 .nav ul li a，浏览器先抓所有 a 元素，再逐个向上查：父节点是不是 li？再往上是不是 ul？再往上是不是带 .nav 的元素？DOM 越深、节点越多，回溯链越长。

而 .nav > ul > li > a 的匹配路径被 > 锁死：只检查每个 a 的**直接父节点是否为 li**，再检查该 li 的直接父节点是否为 ul，依此类推。每一步都限定在 immediate children 范围内，不遍历整棵子树。

高频场景下性能差异最明显

以下三类写法改用 > 后，重排/重绘压力下降最可观：

CSS婚礼策划服务机构宣传网站模板

CSS婚礼策划服务机构宣传网站模板是一款适合提供婚礼策划和婚庆服务机构宣传网站模板下载。提示：本模板调用到谷歌字体库，可能会出现页面打开比较缓慢。

下载

• 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 必须严格对齐的风险。这不是缺陷，而是提前暴露问题的信号。