后代选择器用空格分隔，匹配任意深度嵌套的后代元素，而非固定层级；其核心是语义上的“内容域”关系，结构不稳定时适用，但需避免过度依赖标签路径、精简左侧前缀，并注意从右往左的匹配性能。
后代选择器用空格分隔，不是层级越深越准
后代选择器的核心是“任意深度的嵌套关系”，不是“必须隔几层”。div p 会匹配 <div><p></p></div>，也会匹配 <div><section><article><p></p></article></section></div> —— 中间哪怕嵌了 5 层，只要 p 是 div 的后代，就命中。
常见错误现象：div .btn 本想只改主内容区的按钮，结果页脚里一个 <footer class="btn"></footer> 也被改了——因为这个 footer 恰好在某个 div 内部（比如全局 wrapper），而它又带 .btn 类，就意外中招。
- 判断是否该用后代选择器：目标元素语义上属于某个容器“内容域”，且结构可能动态生成（如 CMS 输出、富文本插入）
- 避免写
header nav ul li a这类 4 层以上选择器；浏览器需遍历整棵子树匹配，性能略差于nav a - 权重会上升：
.content p比p权重高，但比#main .content p低，调试时注意覆盖顺序
后代选择器 vs 子选择器 >：只差一个符号，行为完全不同
section p 和 section > p 看似只差一个 >，但选中范围天差地别。前者捕获所有后代 p，后者只抓直接子 p。
典型误用场景：给文章列表加边距，写了 ul li { margin-bottom: 12px; }，结果嵌套的二级菜单也有了下边距——应该用 ul > li 锁定第一层。
立即学习“前端免费学习笔记（深入）”；
- 当结构稳定、只需控制“第一层”时，优先用
>：更安全、性能更好、意图更明确 - 当内容由外部注入（如 Markdown 渲染、用户编辑器输出），无法保证嵌套深度，才依赖空格后代选择器
- 两者可混用：
.post > h2, .post p表示“只给直接子 h2 加样式，但所有后代 p 都生效”
实际项目中推荐的写法：用类名锚定，少靠 HTML 标签嵌套
纯靠标签路径（如 article section ul li a）写后代选择器，等于把样式和 DOM 结构强绑定。一旦后端改个 <div class="wrapper"> 包一层，整个样式就失效。
更健壮的做法是：用语义化类名作为“锚点”，再接后代选择器。比如 .article-content h3 而非 article h3。
- 好处：HTML 结构可变，只要保留
.article-content类，样式仍生效 - 组合更灵活：
.sidebar .tag-list a比aside ul li a更易维护、更易搜索 - 避免过度依赖 ID：
#main .title权重过高，后续很难被其他规则覆盖
调试时容易忽略的关键点：从右往左读，不是从左往右
CSS 选择器引擎匹配逻辑是“从右往左”：先找所有 a 元素，再逐个检查其祖先是否满足左边条件。这意味着 div p 实际执行的是“找到每个 p，往上查有没有 div 祖先”。
所以，如果你写 body div p，浏览器得为页面每个 p 都查一遍祖先链——哪怕绝大多数 p 根本不在 div 里。这在长列表或复杂 DOM 下会有微小但可测的性能影响。
- 精简左侧：用
.content p替代body .page .content p - 避免无意义前缀：除非真要区分不同 body 状态（如
.dark-mode .content p），否则不用硬加body - 开发者工具里看“Computed”面板时，注意哪条规则真正生效——常有更宽泛的后代规则意外覆盖了你写的子选择器
