子元素选择器“>”仅匹配直接子节点，不穿透嵌套层级；后代选择器空格匹配任意深度后代。例如 ul > li 不选中嵌套第二层的 li，而 ul li 会。
子元素选择器 > 和后代选择器空格的区别
它只匹配父元素的**直接子节点**，不穿透嵌套层级。比如 ul > li 会选中 <ul><li>...</li></ul> 中的 li，但不会选中 <ul><li><ul><li>...</li></ul></li></ul> 里第二层的 li。
常见错误是误用空格代替 >，结果样式意外泄漏到深层结构里。尤其在组件化开发中，一个 div .item 可能影响到嵌套的子组件，而 div > .item 能守住边界。
- 空格（
div .item）：后代选择器，匹配任意深度的后代 -
>（div > .item）：子元素选择器，仅限一级子节点 - 性能上差异极小，但可维护性差别大——
>更明确，更易推理样式作用域
Vue / React 组件中用 > 防止样式穿透
框架组件常带封装好的 DOM 结构，比如 <el-table></el-table> 内部有多层 div 套嵌。若写 .my-table td，可能命中内部任意一层 td；换成 .my-table > .el-table > .el-table__body > tbody > tr > td 就太脆弱，一升级就断。
更务实的做法是控制起点层级 + 合理使用 > 锁定范围：
立即学习“前端免费学习笔记（深入）”；
- 优先给外层容器加唯一类名（如
class="user-list"），再用.user-list > .el-table - 避免链式过长的
>，3 层以内较安全；超过就说明结构耦合太重，该抽局部样式或用:scope（需兼容性评估） - 注意 Vue 的
scoped默认用属性选择器模拟作用域，它不等价于>，两者逻辑不同，别混用期待相同效果
> 在 Flex/Grid 容器中的实际表现
Flex 和 Grid 容器的“直接子元素”就是参与布局的直系项目，这和 DOM 树层级一致，但容易被视觉结构误导。比如一个 div 设了 display: flex，里面放了 <span><b>text</b></span>，那么只有 span 是 flex item，b 不是——所以 .container > * 不会匹配到 b。
- Flex/Grid 的
>选择完全依赖 HTML 结构，不受 display 类型影响（即父元素没设 flex/grid，>仍按 DOM 关系工作） - 想选中所有 flex item？用
.container > :not(.ignore)比.container > *更可控，避免意外选中注释或空文本节点 - IE11 对
>支持完好，但某些旧版 Android WebView 有解析 bug，若需兼容，可用 BEM 命名替代深度限制
调试时怎么确认某个元素是否被 > 选中
浏览器开发者工具里，> 不会高亮路径，得靠排除法验证。最直接的方式是临时加个测试样式，看是否生效：
.parent > .child { outline: 2px solid red !important; }
然后逐层检查 DOM：目标元素的父节点是否恰好是 .parent？中间有没有其他 wrapper 元素？
- 右键元素 → “检查”，看上方最近的父级是否匹配选择器左侧部分
- 在 Elements 面板中删掉疑似中间层的元素，观察样式是否突然出现——这是最快定位“意外隔层”的办法
- 不要依赖“Computed”标签页里的样式来源行号，它不反映
>的实际匹配路径
真正难的不是写对 >，而是写之前就想清楚：这个样式到底该管几层？DOM 结构变没变？有没有 JS 动态插入内容？这些比语法本身更容易让 > 失效。
