子选择器>只匹配直接子元素（“亲儿子”），不匹配孙级及更深层后代；语法为“父选择器 > 子选择器”，空格不可省略，中间插入任何节点即失效。
子选择器 > 只认“亲儿子”，不接受任何中间层
它匹配的条件极其严格：目标元素的 parentNode 必须**正好是**前一个选择器所指的元素。中间插一个 div、section，甚至一个文本节点，就断开关系。
常见错误现象：.menu > li 写好了，但下拉菜单里的 li 完全没样式——因为那些 li 实际在 .menu > ul > li 路径里，不是 .menu 的直接子元素。
- 适用场景：组件第一层结构隔离，比如重置导航主项间距，但不想影响二级菜单内部排版
- 性能略优：浏览器不用递归遍历后代，匹配更快，尤其在长列表或频繁重绘时更可控
- 注意空格：写成
nav>a（无空格）是无效语法；必须是nav > a，空格不可省略
后代选择器空格匹配“整个家族”，不管隔了几代
article p 这种写法会命中 article 内任意深度的 p，哪怕它藏在 article > section > blockquote > div > p 里。
常见错误现象：.card p 统一设字体大小，结果连卡片标题、操作按钮、页脚说明文字里的 p 全被改了——它们都是 .card 的后代，逃不掉。
立即学习“前端免费学习笔记（深入）”；
- 适用场景：富文本区域、CMS 输出内容等结构不可控时，兜底统一基础样式
- 性能代价小但存在：浏览器需向上遍历祖先链确认关系，嵌套极深（>5 层）且元素量大时可能有轻微延迟
- 空格是语法一部分：写成
headerp或headerp都不生效；header p才合法
.a > .b .c 和 .a .b > .c 完全是两回事
组合顺序直接决定层级语义。前者等价于 (.a > .b) .c：先找 .a 的直接子 .b，再找这个 .b 里面所有后代 .c；后者是 (.a .b) > .c：先找 .a 里任意位置的 .b，再找这个 .b 的直接子 .c。
调试时容易误判效果，建议在 DevTools 中右键「Reveal in Elements panel」，逐层看目标元素是否真在预期路径上。
- 混用时别依赖直觉，画 DOM 树草图比背规则更可靠
- SCSS 嵌套中
& > a会编译出.nav > a，但手写 CSS 仍要自己检查空格和符号 - JS 动态插入节点后，
>可能失效——新节点父级可能是 DocumentFragment，而非原始容器
不确定时，先用空格，再收紧范围
与其反复猜结构，不如先写 .block p 看效果；如果范围太大，再加限制：.block > .content p 或 .block__body p。
- 团队协作时，建议用 Stylelint 配置
selector-descendant-combinator-spacing强制校验空格位置 - 避免过度嵌套如
.a .b .c .d：可读性差、性能弱、维护成本高，优先用语义化类名替代 - 真正容易被忽略的是动态渲染场景：Modal、Tab 切换、编辑器插入等内容，
>往往比空格更脆弱
