后代选择器（空格）匹配祖先元素内任意嵌套层级的指定后代元素，如.card p会匹配.card内部所有p元素；子选择器（>）仅匹配直接子元素，如.nav > a只匹配.nav的直接子a元素。

后代选择器（空格）到底匹配哪些元素

后代选择器用空格连接，比如 .card p，它不关心中间隔了几层——只要 p 在 .card 的 DOM 树内部（哪怕套了 section > article > div > span > p），就全中。

• 常见错误：想只改卡片正文的段落，结果连标题、按钮文字、页脚里的 p 全被染色了
• 适用场景：批量统一某区块内所有同类元素样式，例如重置 .modal 内所有 a、ul、button 的基础间距和颜色
• 性能影响：浏览器需向上遍历祖先链确认关系，深层嵌套多时略慢（但日常几乎感知不到）

子选择器（>）为什么只认“亲生儿子”

.nav > a 这种写法极其严格：它只匹配 .nav 的**直接子元素** a，如果 a 被包在 div 或 li 里，哪怕只多一层，就彻底失效。

• 常见错误：写成 .menu > li 却发现下拉菜单项没生效——因为二级 li 实际是嵌套在另一个 ul 里，已不是 .menu 的直接子元素
• 适用场景：组件封装时防止样式穿透，比如只想重置导航栏一级菜单项，完全不管子菜单结构
• 性能略优：跳过深层遍历，匹配更快，尤其在长列表或动态渲染场景下更可控

怎么一眼判断该用空格还是 >

关键就看 HTML 结构里“中间能不能插人”：允许隔层就用空格，必须紧挨着就用 >。

• 检查方法：打开浏览器开发者工具，右键目标元素 → “Reveal in Elements panel”，顺着父节点逐级往上数，看目标元素离祖先元素之间隔了几层标签
• 快速验证：临时加个高亮样式，比如 border: 2px solid red，看哪些元素真被命中
• 混用建议：避免 .container > ul li a 这类写法——> 和空格混搭容易误判层级，团队应约定统一风格（推荐全用 > 控制关键结构，空格用于内容区松散匹配）

兼容性与实际开发中的取舍

两者在所有现代浏览器中都 100% 支持，真正的问题不在兼容性，而在样式泄漏（style leakage）。

• 组件化项目中，.card p 很可能意外覆盖子组件内的 p，而 .card > p 又太窄，漏掉合理嵌套的内容
• 更稳妥的做法：用 BEM 命名 + 明确作用域类，比如 .card__content p，既语义清晰，又避免层级猜谜
• 记住：CSS 不是越“高级”越好，而是谁改

  

  起来最不容易翻车——多数时候，宁可多写一个类，也不靠空格赌结构不变

层级选择的本质不是语法游戏，而是你对 HTML 结构稳定性的预判。空格是信任，> 是设防；用错一次，调试十分钟。