descendant 选择器（空格）匹配任意嵌套层级的后代元素，child 选择器（>）仅匹配直接子元素；前者需向上遍历祖先链，后者仅检查父节点，性能更优且语义更精确。
descendant 选择器（空格）和 child 选择器（>）语义完全不同
很多人以为 div p 和 div > p 只是“多写个 >”的区别，其实它们匹配的 DOM 范围差很多。div p 是 descendant 选择器，会匹配 div 内任意嵌套层级里的所有 p 元素，哪怕中间隔着 5 层 section 和 article；而 div > p 是 child 选择器，只匹配直接子元素——即父节点是 div、且没有其他中间父级的 p。
浏览器解析时 child 选择器通常更快
CSS 选择器是从右往左匹配的。对 div > p，浏览器先找所有 p，再检查其父节点是否为 div；而对 div p，它要找所有 p，再向上遍历整个祖先链，直到找到某个祖先是 div —— 这个过程可能触发多次 DOM 树回溯，尤其在深层嵌套或动态内容场景下开销明显。
- 如果明确只需要直接子元素，优先用
>，避免意外匹配深层嵌套内容 - 用
div p时，注意是否真需要跨层级匹配；很多时候业务逻辑本就只操作直系子元素，却写了宽松选择器 - 在高频重绘/重排场景（如动画、滚动监听），
>的性能优势更可观
容易被忽略的边界情况
这两类选择器在遇到伪元素、文本节点、注释节点时行为一致，但对 DOM 动态变更敏感度不同：当插入一个新 p 到 div 的孙级位置时，div p 规则会立即生效，而 div > p 不会——这既是特性也是陷阱。调试时若发现样式“有时生效有时不”，先查元素实际层级关系，别急着加 !important。
-
div > *:first-child和div :first-child完全不同：前者只匹配div下第一个子元素且是任意类型；后者匹配所有后代中每个容器里的第一个子元素 - 使用 Web Components 或 Shadow DOM 时，
>无法穿透 shadow boundary， - 工具如 Chrome DevTools 的 “Computed” 面板里，会显示最终生效的选择器，但不会标出是 descendant 还是 child 匹配的，需手动比对 DOM 结构
.sidebar p { color: #666; } /* 可能匹配 .sidebar > section > article > p */
.sidebar > p { color: #333; } /* 只匹配 .sidebar 直接子级的 p */
.sidebar > .intro { font-weight: bold; } /* 更推荐：用 class 约束比依赖层级更稳定 */CSS 选择器效率不是靠“越短越好”，而是靠“意图越精确，浏览器越少猜”。用错 和 > 不仅拖慢渲染，还会让样式行为变得难以预测——尤其当其他人后来往 DOM 里插了一层 wrapper。
立即学习“前端免费学习笔记（深入）”；
