根本原因在于计算基准不同：:nth-child按父元素所有子元素位置序号计数，:nth-of-type仅按同类型标签序号计数；混排标签、注释/文本节点、大小写及命名空间均会导致匹配偏差。
为什么 :nth-of-type 和 :nth-child 选不到预期元素
根本原因在于两者计算基准完全不同：:nth-child 看的是父元素下所有子元素的**位置序号**，而 :nth-of-type 只看**同类型标签（如 div、p）的序号**。如果父容器里混着 div、span、p，同一个元素在两个伪类下的“n”值很可能不一致。
常见错误现象：
- 写
li:nth-child(2)想选第二个li，结果选中了第一个li后面那个span（因为它是父元素第 2 个子节点） - 写
p:nth-of-type(1)却没生效——可能前面有个h2，但h2不影响p的 type 计数，真正原因是第一个p前面还有个p（比如被 JS 动态插入或服务端注释干扰）
:nth-child(n) 的实际匹配逻辑
它不关心标签名，只按 DOM 树顺序从 1 开始编号所有直接子元素。哪怕中间夹着注释节点、文本节点（非空格）、script 或 svg，都会计入序号。
实操建议：
- 用浏览器开发者工具的「Elements」面板右键目标元素 → 「Scroll into view」，再逐个展开父节点，数清它前面有多少个
Node（包括注释和换行产生的文本节点） - 避免依赖视觉顺序写
:nth-child(3)，改用更健壮的方式：加 class（如.item--first）或用:is()+ 属性选择器 - 若必须用
:nth-child，先确认父元素结构干净——移除无意义换行、注释、冗余空格文本节点（服务端渲染时尤其要注意）
:nth-of-type(n) 容易被忽略的边界情况
它只统计同名标签，但「同名」指标签名完全一致（区分大小写），且不包含自定义元素的命名空间前缀（如 my-button 和 My-Button 被视为不同类型）。
使用场景与陷阱：
- 适合用于清理模板中「同类内容块」的样式，比如统一设置第 3 个
section的背景色 —— 此时前面的header、nav不干扰计数 - 若页面含 Web Components（如
custom-card），需注意 Shadow DOM 内部的:nth-of-type仅作用于 shadow root 下的直系子元素，无法穿透 - IE 不支持
:nth-of-type（IE8 及以下），如需兼容，得用 JavaScript 补充或改用 class 控制
调试时怎么快速验证哪个伪类生效
别靠猜，用 DevTools 实时验证：
- 在「Styles」面板中手动输入选择器，比如临时加一条
div:nth-child(2) { outline: 2px solid red; }，看是否高亮目标 - 右键元素 → 「Edit as HTML」，删掉它前面的兄弟节点，再观察
:nth-child匹配是否变化 —— 这能立刻验证是否受其他节点干扰 - 对
:nth-of-type，可临时把相邻的同类型标签改成其他标签（如把p改成div），看目标是否仍被选中
最麻烦的情况是：父元素里有动态插入的内容（比如广告脚本插了个 div），导致原本稳定的 :nth-child(2) 突然失效。这种时候，宁可多加一个 class，也别赌 DOM 结构不变。
