p:nth-child(2)不生效是因为它匹配父元素第2个子节点且该节点必须是p，而非第2个p；p:nth-of-type(2)则先收集所有p再编号，不受中间杂节点干扰，更稳定。
为什么写 p:nth-child(2) 总是不生效
它不是在找“第二个 p”，而是在找“父元素下第 2 个子节点，且这个节点恰好是 p”。只要第 2 个子节点是换行符、<div>、注释 <!-- --> 或 <script>，整个选择器就静默失败——连报错都没有。
常见干扰源：
- 服务端模板渲染时自动插入的注释（如
<!-- header -->） - Markdown 渲染器生成的空行，变成 textNode
- 构建工具压缩 HTML 后移除了换行，但开发环境没压缩，导致行为不一致
- CMS 或富文本编辑器插入的广告
<li class="ad">或分隔<div class="separator">
p:nth-of-type(2) 为什么看起来更“稳”
它执行的是两步独立操作：先收集所有 p 元素，再对它们单独编号。前面插了 5 个 <h3>、3 条注释、2 个空格文本节点？全都不影响——第 2 个 p 就是第 2 个 p。
但要注意：
立即学习“前端免费学习笔记（深入）”；
-
div.foo:nth-of-type(2)中的.foo不参与类型判断，只作为附加筛选；真正计数的是所有div标签 - 伪元素（如
::before）、自闭合标签（<img>、<input>）不进入:nth-of-type的同类筛选池，但会参与:nth-child计数 -
<LI>和<li>在 HTML 中视为同一类型，但在 XHTML 模式下大小写敏感（极少遇到）
调试时怎么一眼分清该用哪个
别猜，直接验证：在 DevTools 的 Styles 面板临时加一条 div:nth-child(3) { outline: 2px solid red; }，看红框套在谁身上；再换成 div:nth-of-type(3)，对比两次高亮对象是否一致。不一致？说明中间混了其他 div 或非 div 节点。
更可靠的做法是右键父元素 → “Edit as HTML”，看清真实子节点顺序——不是折叠后的 Elements 视图，而是原始解析树。
关键判断点：
- 想按视觉流式布局控制样式（比如表格整行隔色）→ 优先
:nth-child，但务必限定作用域，如tbody > tr:nth-child(odd) - 想按语义独立编号（比如所有段落、所有按钮）→ 必须用
:nth-of-type - 两者连写（如
li:nth-child(2):nth-of-type(3)）永远不匹配——一个元素不可能同时是第 2 个子节点又是在所有li中排第 3
最容易被忽略的底层细节
伪类匹配永远只发生在**直接父元素的子节点层**。写 section p:nth-child(2)，它不会跨层找嵌套在 article 里的 p；它只看 section 的直接子元素中，第 2 个是不是 p。很多人以为它能递归匹配，结果调试半天发现根本没命中。
另一个隐形陷阱：:nth-child(0) 无效（n 必须 ≥ 1），odd/even 关键字严格小写，IE8 完全不支持 :nth-of-type。
最麻烦的从来不是语法，而是你脑内构建的 DOM 树和浏览器实际解析的不一致——每次写之前，手动画一画子节点分组，比查文档更快定位。
