后代选择器用空格分隔，可匹配任意嵌套层级的后代元素，如.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是两种完全不同的匹配逻辑，别混用
为什么有时候看起来没生效？常见失效原因
不是语法错了，而是结构或优先级出了问题：
Wechat Article Html
下载
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
- 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 的视觉排列“假装”在内部。
