后代选择器（空格）匹配所有嵌套层级的后代元素，如.nav a；子选择器（>）仅匹配直接子元素，如.nav > a；选择取决于html结构稳定性与样式渗透需求。
选 > 还是空格，本质不是“哪个更高级”，而是你愿不愿意为结构稳定性让渡控制力——用 > 意味着你承诺 HTML 不会多套一层容器；用空格意味着你接受样式穿透，但要承担性能和泄漏风险。
后代选择器 .a .b 为什么容易“误中副车”
它不关心中间隔了几层，只要 .b 在 .a 内部任意深度出现，就匹配。这种“无条件穿透”在动态内容里很实用，但也极易失控：
- 常见错误现象：
.card p把卡片标题、按钮文字、footer 里的p全改了，因为它们都是.card的后代 - 使用场景：CMS 输出的富文本、用户可编辑的 article 区域，HTML 结构不可控，必须兜底生效
- 性能影响：浏览器需遍历整个
.a子树，DOM 深度超过 5 层时，重排开销明显高于> - 调试技巧：在 DevTools 里右键元素 → “Break on attribute modifications”，临时删掉某层 wrapper 的 class，看哪些样式突然消失，就能反推是否被过度匹配
子选择器 .a > .b 的“契约感”从哪来
> 不是限制深度，而是强制路径唯一：父 → 直接子，中间不能插任何其他标签。它像一份 DOM 结构协议，一旦违约，样式就失效——这反而是种保护。
- 典型翻车现场：
.nav ul li a在加了<details></details>后仍生效，但语义已错乱；换成.nav > ul > li > a后直接不生效，立刻暴露结构耦合问题 - 适用场景：组件封装（如自定义
<modal></modal>、<form-group></form-group>），边界清晰、结构扁平、不允许样式下渗 - 兼容性无顾虑：IE7+ 全支持，现代项目可放心用
- 注意陷阱：JS 动态插入节点（如 modal 用
document.createElement+appendChild）后，新节点若不是原父元素的直接子节点（比如先塞进 fragment 再 append），>就会失效
混用 :not() 时，空格和 > 的作用半径差异极大
:not() 不改变选择器层级，只过滤已匹配到的元素。它的“过滤范围”完全取决于前面的选择器写法：
-
.list > li:not(.disabled)安全：只对.list的直接子li做判断，嵌套菜单里的li根本不参与匹配 -
.list li:not(.disabled)危险：先匹配所有.list内任意深度的li，再剔除带.disabled的——结果二级菜单里本该禁用的li被意外启用 - 真实案例：表格行用
.table-row，其中一列渲染小列表也用了li，.table-row li:not(.hidden)会干扰行高计算
真正容易被忽略的，是当父容器本身由 JS 动态创建或 fragment 插入时，> 的“直接子”语义会失效——因为 DOM 关系重建后，新节点未必满足原始父子链。这时候空格反而更鲁棒，或者得配合属性选择器（如 [data-modal] > .content）来锚定上下文。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
