后代选择器用空格分隔，匹配任意嵌套深度的后代元素；div > p 是子选择器，div ~ p 是兄弟选择器；空格不可省略，伪元素不能作左侧主体，过深嵌套影响性能。
后代选择器就是空格，不是 > 也不是 ~
很多人一看到“后代”就下意识想到子元素，结果把 div p 写成 div > p，甚至试 div ~ p。其实 html5 里“后代选择器”特指用空格分隔的层级关系：只要 p 在 div 内部任意嵌套深度，哪怕中间隔着 5 层 section 或 article，都算匹配。
常见错误现象：div p 没生效，其实是 CSS 文件没加载、优先级被覆盖，或者目标 p 其实不在那个 div 的 dom 子树里（比如被 js 移走了）。
-
div p匹配所有在div内的p，不管嵌套几层 -
div > p只匹配div的直接子元素p（子选择器） -
div ~ p匹配跟在div后面的同级p（通用兄弟选择器） - 空格不能省略，
divp是无效选择器，会被浏览器忽略
后代选择器不支持伪元素作为左侧主体
你不能写 ::before p 或 :hover p 这类东西——伪元素和伪类本身不生成真实 DOM 节点，没法当“祖先”。浏览器会直接丢弃整条规则，连警告都不报。
使用场景：想给某个状态下的元素内部的后代加样式？得把伪类放在最左边，比如 button:hover span，而不是 button span:hover（那是给 span 加 hover 状态）。
立即学习“前端免费学习笔记（深入）”；
-
a:hover em✅ 有效：鼠标悬停在a上时，其内部所有em -
a em:hover❌ 是另一回事：只影响em自身 hover，跟a无关 -
::before span❌ 语法错误，CSS 解析失败 - 真要控制伪元素内容里的结构？做不到。伪元素内容是字符串或生成节点，不可再选
性能敏感场景下，避免过度嵌套的后代选择器
像 body div header nav ul li a span.icon 这种写法，浏览器匹配时要从右往左逐层回溯，每一步都要查父节点，DOM 深、选择器长，渲染引擎压力明显上升。现代浏览器虽做了优化，但老设备或复杂单页应用里仍可能卡顿。
兼容性影响：这种写法本身所有浏览器都支持，问题出在“可维护性”和“运行时开销”上，不是能不能用，而是值不值得这么写。
- 优先用语义化 class，比如
.nav-icon，比靠层级定位快得多 - 如果必须依赖结构，尽量控制在 3 层以内，如
.header nav a - webpack/Vite 构建时若用了 CSS 压缩工具，过深的选择器可能被误删（某些插件有深度阈值）
- 用 DevTools 的“Rendering → Paint flashing”能直观看出哪些区域因选择器重绘频繁而闪烁
后代选择器对动态插入的内容一样生效
这是它和 JS 直接操作 class 的关键区别：只要新插入的 HTML 片段符合已有 CSS 规则的结构，样式立刻生效，不用手动 re-init。
使用场景：SPA 中用 innerHTML 或 insertAdjacentHTML 插入内容，或者通过模板引擎渲染区块，只要结构对，article .meta time 这类规则自动接管。
- 动态插入的
<p>hello</p>到已有<div class="content"></div>中，.content p立刻生效 - 但若插入的是
<p class="no-style">hello</p>，而你的规则是.content p:not(.no-style)，那就不匹配 - 注意 Shadow DOM：默认情况下，后代选择器跨不出 shadow boundary，
my-el p不会匹配其 shadow root 里的p - 如果插入的是未闭合标签或非法 HTML（如
<p>text</p> <div>），浏览器纠错后 DOM 结构可能偏离预期，导致选择器失效 <p>真正容易被忽略的是：后代选择器看起来简单，但它的“松散性”既是优势也是隐患——结构稍变，样式就悄悄失效，而且很难一眼从 HTML 里反推是哪条 CSS 在起作用。</p> </div>