nth-child按子节点总序号匹配,不区分类型;nth-of-type仅在同类型兄弟中计数。二者均作用于直接子元素,IE9+支持,性能无差异。

nth-child 选的是位置,不关心元素类型
只要父元素下第 常见错误现象: 使用场景典型:文章正文里想给“第 3 个段落”加样式,不管前面有没有 立即学习“前端免费学习笔记(深入)”; 假设有如下 HTML: 第一段 第二段 那么: 如果删掉 两者在现代浏览器中解析开销几乎一致,都不是性能瓶颈。真正影响渲染效率的是选择器整体复杂度(比如嵌套过深、通配符滥用),而不是 兼容性方面,IE9+ 都支持,但 IE8 及更早版本完全不支持这两个伪类 —— 如果还要兼容,得用 class 手动标记或 JS 补充。 最常被忽略的一点:它们都只作用于**直接子元素**。写成 n 个子节点恰好满足条件(比如 2n),就命中,哪怕它是 、div:nth-child(2) 没生效,其实是因为第二个子节点是 ,不是
,所有 :nth-child(n) 的匹配结果都会偏移:nth-child(3n+1),但始终基于总子节点序号计算nth-of-type 只看同类型兄弟节点的顺序
:nth-of-type(n) 会先筛选出和当前选择器标签名一致的兄弟节点(比如所有 ),再在这些同类节点里按出现顺序编号,取第 n 个。、 或空 就行。
)的“类型”,因为它们没有结束标签,不参与同类型计数逻辑::before)不参与任何 :nth- 计算,它们不在 DOM 子节点中混用时容易踩的坑:div:nth-child(2) ≠ div:nth-of-type(2)
标题
p:nth-child(2) → 匹配“第一段”,因为它是第 2 个子节点p:nth-of-type(2) → 匹配“第二段”,因为它是第 2 个
div:nth-child(3) → 匹配那个 div:nth-of-type(1) → 同样匹配它,因为它是唯一一个 ,p:nth-child(2) 就会从匹配“第一段”变成匹配“第二段”,而 p:nth-of-type(2) 始终不变。性能与兼容性其实没差别
nth-child 和 nth-of-type 的差异。section p:nth-of-type(1) 是合法的,但这里的 :nth-of-type(1) 是针对每个 在其**各自父容器内**计数,不是在整个 下所有 统一排序。










