后代选择器 .a b 匹配所有在 .a 内任意嵌套层级的 b 元素，不关心中间隔几层；子选择器 .a > b 仅匹配 .a 的直接子元素 b，中间不可有其他节点。
后代选择器 .a b 为什么总比你预期的“多选中几个”
因为它的匹配逻辑是“向下遍历整棵子树”，只要 b 在 a 的 DOM 树内部（哪怕中间隔了 section > article > div > span），就命中。浏览器不关心路径长度，只确认“祖先-后代”关系成立。
常见错误现象：.form-group label 把弹窗里的 label、卡片内部的 label 全染红了；.nav li 顺手把二级下拉菜单也套上 padding。
使用场景适合内容区兜底：比如 CMS 输出的富文本、用户粘贴的 HTML，结构不可控时，用空格能确保样式生效。
- 必须写空格——
.headerp是无效选择器，.header p才对 - 性能影响轻微，但 DOM 深度超 10 层且频繁重排时，可感知延迟
- 调试技巧：在 DevTools 里右键元素 → “Break on attribute modifications”，切换选择器看哪些元素突然失样式
子选择器 .a > b 失效时，90% 是 HTML 结构“多了一层”
.a > b 只认“亲儿子”，要求 b 的父节点必须是 a，中间不能插任何其他元素。哪怕只是多包了个 div 或 li，就彻底断连。
典型误用：ul > li 写得严丝合缝，结果 JS 动态插入的 modal 里，新 li 是 fragment 插入后重建的 DOM 关系，父级已不是原始 ul，直接失效。
适用场景是组件边界清晰处：导航栏一级项、表单字段直系标签、卡片主内容区块。
- 不要混搭：
.container > ul li这种写法极易误判——前半段用>锁死层级，后半段又用空格放行，语义混乱 - 性能略优：跳过深层遍历，长列表渲染或动画帧敏感场景更可控
- 兼容性无顾虑：IE7+ 全支持，问题不在能不能用，而在“敢不敢重构 HTML”
.a > .b .c 和 .a .b > .c 完全是两回事
顺序和符号位置决定作用域归属，不是简单“谁管谁”。前者要求 .b 是 .a 的直接子，.c 是 .b 的任意后代；后者要求 .b 是 .a 的任意后代，.c 是 .b 的直接子。
容易踩的坑：
- SCSS 嵌套中写
.a { > .b { .c { } } }，编译后是.a > .b .c，不是你想的.a .b > .c -
:not()不改变作用域层级——.table-row li:not(.hidden)会把小列表里的li也卷进来，干扰主表行高计算 - 动态插入节点后，父级关系可能变化，
>比空格更脆弱
什么时候该放弃 >，退回到空格写法
当父容器本身由 JS 动态生成（比如 modal、tooltip、虚拟滚动 item），且插入方式不保证父级关系稳定时，> 就不可靠。这时候要么加固定属性锚点（如 [data-modal] > .content），要么直接用空格兜底。
真正难处理的不是语法，而是团队对“结构是否可控”的判断分歧。有人觉得 HTML 永远不该改，于是全用空格；有人坚持组件封装必须锁死层级，结果每次 CMS 更新都得修样式。
最容易被忽略的一点：空格不是“宽松”，而是“信任”；> 不是“高级”，而是“设防”。用错一次，调试十分钟——尤其在多人协作、跨项目复用组件时。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
