nth-of-type能选中子元素里的第n个p，但只按同类型兄弟元素位置计数，不考虑嵌套层级或非目标标签节点。
nth-of-type 能不能选中子元素里的第 n 个 <p></p>
能，但只认“同类型兄弟元素”的位置，不看嵌套层级。它数的是父容器下所有同标签名的兄弟节点，不是当前元素内部的子元素。
常见错误现象：div > p:nth-of-type(1) 想选第一个 <p></p>，结果没生效——因为父 <div> 下第一个子可能是 <code><h2></h2> 或 <span></span>，<p></p> 是第二个同类型兄弟才被算作 nth-of-type(1)。
- 使用场景：给文章段落加样式时，跳过开头的
<h2></h2>、<img alt="CSS nth-of-type选择器进阶_在同类标签中按索引定位" >，只对纯<p></p>序号控制 -
nth-of-type(2n)和nth-child(2n)效果常不同：前者只统计<p></p>，后者统计所有子元素 - 性能影响极小，但过度嵌套 + 大量兄弟节点时，浏览器仍需遍历计算类型顺序
为什么 :nth-of-type(3) 有时什么都没匹配到
因为目标标签在兄弟中根本排不到第 3 位——比如父元素只有两个 <li>，那 li:nth-of-type(3) 永远不会命中。
更隐蔽的情况：HTML 中有注释、文本节点（比如换行空格）或动态插入内容，它们不影响 nth-of-type 计数，但可能让开发者误判“第几个”。
立即学习“前端免费学习笔记（深入）”；
- 调试建议：用浏览器开发者工具选中父元素，手动数一遍同标签名的兄弟节点（忽略注释和纯文本）
- 注意空格换行：写成
<ul> <li>a</li> <li>b</li> </ul>和多行缩进版，在 DOM 树里兄弟结构一致，不影响计数 - 服务端渲染或 JS 动态插入后，DOM 结构变化可能导致原规则失效
nth-of-type 和 nth-child 在真实项目里怎么选
看你要按“类型独立排序”还是“整体位置排序”。大多数 UI 组件（如卡片列表、表单字段组）用 nth-of-type 更可控；表格行、栅格列这类强顺序结构，nth-child 更直观。
- 兼容性：两者都支持 IE9+，但
nth-of-type在老 Android WebView（4.3 及以下）有少量解析 bug - 参数差异：
an+b写法通用，但nth-of-type(odd)只匹配该类型中的奇数位，不是整个父容器的奇数子元素 - 别混用：写成
div p:nth-of-type(1)是合法的，但它找的是每个<div> 下第一个 <code><p></p>，不是整个页面第一个<p></p>伪类里写变量？CSS 自定义属性能不能参与
nth-of-type计算不能。
nth-of-type是纯静态选择器，不接受 CSS 变量、calc() 或运行时值。所谓“动态 nth”必须靠 JS 控制 class 或属性，再用属性选择器配合。容易踩的坑：有人试图写
p:nth-of-type(var(--n))，浏览器直接忽略整条规则，控制台也不会报错，只是静默失效。- 替代方案：给目标元素加
data-index="3"，然后用p[data-index="3"] - 如果要批量控制，JS 批量加 class 如
p--first、p--second更稳定 - CSS-in-JS 或构建时预处理（如 Sass 循环）可以生成固定规则，但仍是静态输出
真正难的从来不是语法，而是你数兄弟节点时，有没有把那个看不见的
<script></script>标签也算进去。 - 替代方案：给目标元素加
