后代选择器用空格分隔，可匹配任意嵌套层级的后代元素，如.container .item会选中.container内所有层级的.item；而子选择器>仅匹配直接子元素。
直接用空格分隔的选择器就能选中非直接后代元素，不需要额外技巧。所谓“非直接后代”，其实就是后代选择器的默认行为——它天然覆盖所有嵌套层级，包括孙子、曾孙甚至更深的节点。
后代选择器语法：空格就是关键
写 .container .item 时，.item 只要出现在任意层级的 .container 内部（哪怕中间隔着 div、section、article），都会被匹配。浏览器从右往左解析：先找所有 .item，再逐个往上查祖先是否含 .container。
- ✅ 正确：
.sidebar a匹配<div class="sidebar"><nav><ul><li><a>Link</a></li></ul></nav></div> - ❌ 错误预期：
.sidebar > a—— 这根本不会生效，因为a几乎不可能是.sidebar的直接子元素 - ⚠️ 注意：
.sidebar .item和.sidebar > .item是两种完全不同的匹配逻辑，别混用
为什么有时候看起来没生效？常见失效原因
不是语法错了，而是结构或优先级出了问题：
html-to-pptx-converter
下载
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
- HTML 实际嵌套层级和你预想的不一致（比如
.item其实写在了.sidebar外面，只是视觉上靠得近） - CSS 特异性（specificity）被更高权重的规则覆盖，例如
div#main .item比.sidebar .item权重高 - DOM 是 JS 动态插入的，而样式表加载早于元素挂载，导致初始未匹配（需确认是否触发了重排或使用
:has()等新特性补救） - 用了
>却误以为是“更宽松”的后代匹配，结果只锁死了第一层
:nth-of-type() 套后代选择器的写法陷阱
像 .entry:nth-of-type(odd) .imageContain 这种组合，空格不能省——.entry:nth-of-type(odd).imageContain（无空格）会变成“同时拥有两个 class 的单个元素”，语义全变。
- ✅ 正确：
.entry:nth-of-type(odd) .imageContain→ 找 odd 位置的.entry，再在里面找任意层级的.imageContain - ❌ 错误：
.entry:nth-of-type(odd) > .imageContain→ 强制要求.imageContain必须是它的**直接子元素**，实际结构往往不满足 - ⚠️ 注意：
:nth-of-type()是按同级兄弟元素类型计数的，跟 class 无关；如果父容器里混着h2、p、div.entry，那div.entry:nth-of-type(odd)的“odd”可能不是你肉眼看到的第 1、3、5 个
真正容易被忽略的是浏览器解析顺序：它不关心 HTML 缩进或视觉缩进，只认真实的 DOM 树路径。哪怕你写了十层嵌套，只要路径存在，.a .b 就能命中——前提是那个 .b 确实被某个 .a 的祖先包裹着，而不是靠 CSS Grid 或 Flex 的视觉排列“假装”在内部。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
