nth-of-type 只认同类型标签，不认类名或属性
nth-of-type 的计数逻辑非常“死板”：它只看兄弟节点中**相同 HTML 标签名**的元素顺序，完全忽略 class、id、data-* 甚至内联样式。比如三个 <div> 中夹着一个 <code><p></p>，再跟一个 <div>，那第 4 个 <code><div> 是 <code>div:nth-of-type(4)，中间的 <p></p> 完全不参与 div 的计数。
常见错误现象：div.item:nth-of-type(2) 本意是选第二个带 item 类的 div，但实际效果等同于 div:nth-of-type(2) —— 类名在这里毫无作用。
- 想按类筛选+序号控制？得用 JS 或预处理器（如 Sass 的
@for+:nth-child配合结构假设） - 如果父容器里只有目标类型一种标签（比如全是
<li>），那nth-of-type和nth-child行为一致 - 注意 SVG 中
<g></g>、<path></path>等也是独立标签类型，path:nth-of-type(3)只统计<path></path>兄弟
想对“某类子元素”做间隔样式，优先考虑 :nth-child + 结构前提
真正按“第 N 个带某 class 的元素”来匹配，在纯 CSS 里做不到。但多数实际场景下，你可以靠 DOM 结构可控性绕过去——比如列表项固定由 <li class="item"> 组成，中间没有其他类型标签干扰。
这时用 li.item:nth-child(odd) 比 li.item:nth-of-type(odd) 更安全，因为 nth-child 至少能保证选中的是 li 且带 item 类（虽然计数仍按位置），而 nth-of-type 连类名都不认。
立即学习“前端免费学习笔记（深入）”；
- 若结构中混有
<li class="divider">或<li class="loading">，nth-child的序号会跳变，需手动算偏移或改用 JS -
nth-child(2n+1)和nth-child(odd)等价，但前者更利于动态计算（比如2n+3表示从第 3 个开始奇数位） - 兼容性无差别：两者在 IE9+、现代浏览器中表现一致
伪类嵌套失效：:nth-of-type 不能和 :not 组合过滤类型
你不能写 div:not(.ignore):nth-of-type(2) 期望它跳过带 ignore 类的 div 再数第二个。CSS 解析时，:nth-of-type(2) 先执行，选出第二个 <div>；<code>:not(.ignore) 后执行，只是判断这个已选中的 div 是否满足条件。如果第二个 div 刚好是 .ignore，整条规则就匹配失败，不会自动找第三个。
错误现象：一组 <div> 中第 2 个是 <code><div class="ignore">，其余都带 <code>active 类，div.active:nth-of-type(2) 无法命中任何元素。
- 解决方案只有两个：重构 HTML（把
.ignore换成非div标签，如<span></span>），或改用 JS 动态加类 -
:is()和:where()也无法改变nth-of-type的底层计数逻辑 - 别试图用
div:nth-of-type(2):not(.ignore), div:nth-of-type(3):not(.ignore)硬凑——维护成本高且不可扩展
性能与可维护性提醒：避免深层嵌套 + 大范围 nth 计算
CSS 引擎对 nth-of-type 的实现依赖遍历兄弟节点，当父容器下有数百个同类型子元素（比如虚拟滚动未启用的长列表），且你还写了 div:nth-of-type(100n+7) 这类复杂表达式，可能触发重排开销——尤其在低功耗设备上。
- 真要处理大量同类型元素的规律样式？优先用 JS 批量加
data-index或分组类名（如row-group-1） -
nth-of-type的表达式越简单越好：(2n)比(2n+100)快，(n)实际等价于无限制，不如直接去掉 - 多人协作项目里，
nth-of-type(3n+2)这种写法容易让后续开发者误判起始位置，加注释不如改用明确 class（如third-in-group）
归根结底，nth-of-type 是个结构工具，不是查询工具。它只回答“第几个同标签兄弟”，不回答“第几个符合条件的元素”。这点没理清，所有花式写法都会在某个 DOM 变动后突然失效。
