后代选择器 .container p 匹配 .container 内任意深度的 p 元素，而子选择器 .container > p 仅匹配其直接子级 p；本质区别在于匹配路径是否严格限定为一层，而非嵌套深度。
后代选择器 .container p 和子选择器 .container > p 本质区别在哪
区别不在“嵌套深不深”，而在“匹配路径是否严格限定一层”。.container p 匹配所有在 .container 内任意深度的 p 元素（包括孙子、曾孙）；.container > p 只匹配直接子级的 p，即父元素必须是 .container，且中间不能隔其他标签。
常见错误现象：.header .title 原本只想改顶部标题，结果侧边栏里也冒出来一个 .title 被误中——这就是没意识到它会穿透多层 DOM 树。
- 使用场景：需要精确控制作用范围时（比如组件封装），优先用
>；需要灵活捕获深层结构（如富文本内容区统一排版），才用空格 - 参数差异：二者语法上只差一个
>，但浏览器解析逻辑完全不同——后代选择器需遍历整棵子树，子选择器只查第一层子节点 - 性能影响：DOM 深度大时，
.a .b的开销明显高于.a > .b，尤其在频繁重排/重绘的页面中
为什么 div ul li a 比 div > ul > li > a 更容易出问题
前者看似“更宽松”，实则隐含三重风险：DOM 结构稍有变动就失效、样式意外泄漏到非预期分支、开发者误以为层级固定而不敢重构 HTML。
典型翻车现场：把 <nav><ul><li><a></a></li></ul></nav> 改成 <nav><ul><li><details><summary><a></a></summary></details></li></ul></nav> 后，原来写的 nav ul li a 依然生效，但语义已错乱——a 不再是导航项，而是折叠面板里的操作链接。
立即学习“前端免费学习笔记（深入）”；
- 子选择器强制结构契约：
nav > ul > li > a在上述改动后直接失效，反而帮你暴露了 HTML 与 CSS 的耦合问题 - 兼容性无差别：两者从 IE7 起就完全支持，不用考虑降级
- 调试技巧：Chrome DevTools 里右键元素 → “Break on attribute modifications” 配合修改 class，能快速验证哪个选择器真正触发了样式变化
:not() 和子选择器混用时，为什么 .list > li:not(.disabled) 是安全的，而 .list li:not(.disabled) 很危险
因为 :not() 本身不改变选择器的作用域层级。加了 > 后，:not() 只作用于直接子 li；去掉它，:not() 就可能匹配到嵌套在 li 里的其它 li（比如列表里嵌套了二级菜单），导致本该禁用的子项被意外启用。
真实案例：某后台表格行用 .table-row 类，其中某列内又渲染了一个小列表，也用了 li。若写 .table-row li:not(.hidden)，那个小列表的 li 也会被算进来，干扰主表行高计算。
- 关键原则：
:not()前的选择器决定了它的“作用半径”，务必先用>或其它方式收窄范围 - 不要试图靠
:not(.parent > li)来反向排除——CSS 不支持这种写法，:not()里只能是简单选择器或伪类 - 替代方案：对嵌套结构单独加命名空间类，比如
.table-row__sublist li，比依赖:not()更可控
现代框架（React/Vue）组件中，还该不该纠结后代 vs 子选择器
该，而且更该——因为组件模板往往结构清晰、层级可控，恰恰是最适合用 > 建立样式契约的地方。
很多人以为“组件隔离了 DOM，所以随便写都行”，但忘了 CSS 是全局的。一个 Button 组件里写了 .btn span，结果父组件恰好有个 span 插在 Button 里面（比如加图标），样式就穿帮了。
- 推荐做法：组件根元素带唯一前缀类（如
my-button），内部默认用>连接，除非明确需要穿透（如支持插槽内容定制） - 注意 CSS-in-JS 或 CSS Modules 并不自动解决这个问题——它们只是避免类名冲突，但选择器逻辑照旧生效
- 最易被忽略的一点：伪元素（
::before/::after）和伪类（:hover）不受>限制，它们绑定在元素自身，不是“子节点”
