根本原因在于计算基准不同：:nth-child按父元素所有子元素的位置序号计数，:nth-of-type仅按同标签名元素的序号计数；中间夹杂其他标签或空白节点会导致两者结果不一致。
为什么 :nth-of-type 和 :nth-child 选中的元素经常不一致
根本原因在于两者计算基准完全不同：:nth-child 看的是父元素下所有子元素的**位置序号**，而 :nth-of-type 只统计**同类型标签（即相同 html 标签名）** 的序号。只要中间夹了其他标签，比如
前面有 ，结果发现没生效——很可能因为第一个子元素其实是
或 常见错误现象：写 li:nth-child(2) 想选第二个
里的注释、文本节点，或一个
。
- dom 中的空白文本节点（换行、缩进）会被
:nth-child 计入，但不会影响 :nth-of-type
-
和
（大小写混用）在 HTML 中视为同一类型，但严格 xml/ xhtml 模式下可能被区分（实际极少遇到）
- 自定义元素如
完全无关，各自独立计数
:nth-child(2) 与 :nth-of-type(2) 在混合标签结构中的行为对比
假设有如下 HTML：
intro - first
note
立即学习“前端免费学习笔记（深入）”；
- second
此时：
-
li:nth-child(2) → 匹配第一个
（它是父
的第 2 个子元素）
-
li:nth-child(4) → 匹配第二个
（它是第 4 个子元素）
-
li:nth-of-type(1) → 匹配第一个
（它是第 1 个
）
-
li:nth-of-type(2) → 匹配第二个
（它是第 2 个
）
可见：想稳定选中“第 N 个同类型元素”，必须用 :nth-of-type(N)；想选“父容器中第 N 个位置上的元素且恰好是某类型”，才用 :nth-child(N) 配合类型限定。
伪类混用时的优先级与解析陷阱
css 解析器按从左到右顺序匹配，:nth-child 和 :nth-of-type 是独立伪类，不能“组合逻辑”使用（例如 li:nth-child(2):nth-of-type(3) 这种写法永远不匹配任何元素——因为一个
不可能同时是父元素第 2 个子元素又是在所有
中排第 3）。
- 多个伪类连写是「与」关系，必须全部满足；不满足任一即丢弃
-
li:nth-child(2n) 表示“位置为偶数的子元素，且是
”，不是“第 2、4、6… 个
”
- 浏览器不会回溯重算——一旦某个伪类不成立，整个选择器失效，不尝试其他解释路径
调试时如何快速确认到底哪个元素被选中
最可靠方式是打开浏览器开发者工具，在 Elements 面板中手动逐个检查目标父元素的子节点构成（包括注释和文本节点），再对照 CSS 选择器推演。
- 在 chrome/firefox 中右键父元素 → “Edit as HTML”，删掉疑似干扰节点（如空行、
- 用 js 快速验证：
document.querySelectorAll('li') 查看所有
，再用 Array.from(parent.children).map((el, i) => [i+1, el.tagName]) 查看真实子元素序号与类型
- 避免依赖“看起来是第几个”，DOM 树结构才是唯一依据
真正容易被忽略的，是那些看不见的节点：换行符生成的文本节点、HTML 注释、服务端模板注入的空
——它们都参与 :nth-child 计数，却不占视觉空间。