后代选择器（空格）匹配祖先元素内任意嵌套层级的指定后代元素，如.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 结构稳定性的预判。空格是信任，> 是设防；用错一次，调试十分钟。