css子元素选择器“>”严格匹配直接子元素，如ul > li仅选第一层li，不匹配嵌套更深的li；而空格为后代选择符，会匹配任意层级后代。
子元素选择器（>）只匹配直接子元素
写 ul > li 时，它只会选中 <ul></ul> 的**第一层** <li>，跳过所有嵌套更深的。如果目标 <li> 被包在 <div> 或另一个 <code><ul></ul> 里，哪怕结构看起来“应该能选到”，它也完全不生效。
常见误判场景：
- HTML 是
<ul><div><li>Item</li></div></ul>，但写了ul > li→ 不匹配，因为<li>不是<ul></ul>的直接子节点 - 用了
.container > .item，但实际 DOM 中.item在.container > .wrapper > .item里 → 同样失效 - JS 动态插入后结构变化，比如把
<li>移进了新容器，但 CSS 没更新选择器
验证方法：在开发者工具 Elements 面板中右键父元素 → “Edit as HTML”，肉眼确认子节点是否真为你要的目标标签。
> 和空格（后代选择器）混淆导致误判
这是最常踩的坑：.parent > .child 和 .parent .child 完全是两回事。前者要求严格父子关系，后者只要在任意嵌套层级里出现就行。
比如这段 HTML：
<div class="parent"> <p>Text</p> <div class="child">Target</div> </div>
.parent > .child 能匹配；但改成 .parent > p > .child 就不行——因为 <p></p> 下根本没有 <div class="child">。<p>检查要点：</p>
<ul>
<li>打开 Styles 面板，看你的规则是否出现在目标元素上；没出现 = 选择器根本没命中</li>
<li>注意类名拼写、大小写、连字符（<code>.btn-primary ≠ .btnprimary）
[data-type="menu"] 不会匹配 data-type="menu main"，得用 [data-type~="menu"]
父容器下没有符合类型和层级的直接子元素
> 是强约束型选择器，它不“宽容”。哪怕 DOM 看起来差不多，只要中间多一层、少一层、换一个标签，就断掉。
典型失败案例：
- 想用
nav > a选导航链接，但实际是<nav><ul><li><a></a></li></ul></nav>→a的父节点是li，不是nav - 服务端模板渲染时自动加了 wrapper
<div class="ssr-wrapper">，把原有结构“垫高”了一层<li>Shadow DOM 或 Vue/React 组件作用域内，外部写的 <code>>选择器压根进不去
此时不能靠猜，要用开发者工具逐层点开父节点，确认「目标元素的 parentNode 是否真是你写的那个父选择器所指的元素」。
伪元素或动态内容干扰了直接子关系
> 只认真实 DOM 节点，对注释、文本节点、display: contents 元素或 JS 插入的临时占位符不敏感——但它依然按原始结构计数。
例如：
- First
这时 ul > li 仍能匹配，因为注释不是元素节点；但若写成：
-
\n
- First
换行符会被解析为文本节点，<li> 就不再是第一个子节点，不过这不影响 > 匹配（它不要求“第一个”，只要求“直接子”）。
真正危险的是：
- 用
innerHTML批量插入 HTML 时漏掉了外层包裹，导致结构错位 - 使用
display: contents的父元素，其子元素在视觉上“升了一级”，但 DOM 层级没变 →>仍按原层级匹配，容易误以为失效 - CSS-in-JS 或 CSS Modules 对类名做了哈希重命名（如
Button-module__item___3xK9p），直接写.item必然失败
这类问题往往不报错，也不显示样式，唯一可靠路径是：打开 Elements 面板，手动点击目标元素，看 Styles 里有没有你写的那条规则——没有，就是选择器没对上号。
