p:nth-child(2)先定位父元素第2个子节点再判断是否为p，若该节点非p则匹配失败；p:nth-of-type(2)直接选取第二个p元素，无视中间干扰节点。
为什么p:nth-child(2)有时选中第一个p，有时根本没效果
因为它的执行逻辑是两步：先定位父元素的第 2 个子节点，再判断它是不是 p。如果第二个子节点是换行符（textNode）、div、注释或 span，那整个选择器就匹配失败——哪怕后面有十个 p，也一个都不中。
常见错误现象：p:nth-child(2) 在本地开发时生效，上线后样式消失 → 很可能是构建工具压缩 HTML 去掉了换行，或服务端模板动态插入了不可见节点，悄悄改变了子节点序号。
使用场景：适合结构绝对干净的纯列表，比如 ul > li，且中间不会插入分隔线、标题、空格或注释。
什么时候必须用p:nth-of-type(2)而不是p:nth-child(2)
p:nth-of-type(2) 是“找第二个 p”，不管它前面有多少干扰项；p:nth-child(2) 是“找第二个位置上坐着的 p”，位置错了就全盘失效。
立即学习“前端免费学习笔记（深入）”；
以下结构中，p:nth-of-type(2) 总能命中第二个 p，而 p:nth-child(2) 完全不匹配：
<article><h2>标题</h2><time>2026-09-02</time><p>第一段</p><p>第二段</p></article><form><label>用户名</label><input type="text"><span class="error">必填</span><p>提示文字</p></form>
容易踩的坑：article p:nth-child(2) 不会跨层查找——它只看 article 的直接子元素。如果 article 下第一个子是 header，第二个是 main，那这个选择器压根不会命中任何 p。
button:nth-child(3) 和 button:nth-of-type(3) 哪个更严格
button:nth-child(3) 更严格：它要求父元素的第 3 个子节点**必须是 button**，否则整个选择器无匹配。适合固定布局，比如工具栏中“第三个位置必须放确认按钮”的强约束场景。
button:nth-of-type(3) 更宽容：它只收集所有 button 元素，取其中第 3 个，不管它前面混了多少 div、span 或空白文本节点。适合 React/Vue 动态渲染的表单或卡片，按钮顺序不固定但类型明确。
参数差异举例：button:nth-child(odd) 按总序号奇偶筛选（第 1、3、5… 个子节点），而 button:nth-of-type(odd) 按 button 自身出现顺序奇偶筛选（第 1、3、5… 个 button）——在混排 DOM 中结果常完全不同。
伪类作用域永远只限于直接父元素的子节点
这是最容易被忽略的一点：section p:nth-of-type(2) 不会递归搜索 section 下所有后代 p，它只对 section 的**直接子元素中的 p** 计数。如果 p 嵌套在 article 或 div 里，它就完全不在作用范围内。
同理，ul li:nth-child(2) 只管 ul 的子 li，不会理会 ul > ol > li 或 ul > div > li。
复杂点在于：DOM 中看不见的节点（换行、空格、注释）真实参与 :nth-child 计数，但完全不参与 :nth-of-type 计数——你得打开浏览器开发者工具的“显示空白节点”选项，才能真正看清谁在第几个位置。
