li:nth-child(2)未选中第二个li，因其匹配父元素下第2个子节点且必须是li，若该位置为注释、div或空白文本节点则失效；而li:nth-of-type(2)只统计li标签序号，更稳定可靠。
li:nth-child(2) 为什么没选中第二个 li
因为 nth-child 数的是父元素下所有子节点的**位置序号**，不是“第几个 li”。只要第二个子节点不是 li（比如是注释、div、换行产生的文本节点，甚至一个 span），整个选择器就失效。
常见现象：
- 写
li:nth-child(2)，结果高亮了第一个li后面那个span—— 因为它恰好是父元素第 2 个子节点 - 本地开发时样式正常，上线后崩了 —— 服务端模板多加了一行注释
，导致所有nth-child序号偏移 - 用 Prettier 格式化 HTML 后样式错乱 —— 新增的换行和缩进生成了空白文本节点，被计入
nth-child计数
p:nth-of-type(2) 为什么比 p:nth-child(4) 更可靠
nth-of-type 只看同名标签的出现顺序，完全跳过其他类型节点。它不care前面有没有 h3、div、注释或空格文本 —— 只要它是父元素里第二个 p，就稳稳命中。
实操建议：
- 在 DevTools 的 Elements 面板里右键目标
p→「Edit as HTML」，手动删掉它前面的兄弟p，再看p:nth-of-type(2)是否立刻切换到下一个 —— 这能验证你是否真在按“类型顺序”思考 - 不要写
.post p:nth-child(4)去选“第二段正文”，改用.post p:nth-of-type(2) - 如果必须用
nth-child，先确认父元素 DOM 干净：移除无意义注释、压缩模板输出、避免 JS 动态插入干扰节点顺序
:nth-child(odd) 和 :nth-of-type(odd) 在混合结构中结果不同
两者都支持 odd、even、3n+1 等表达式，但“n”的基数完全不同：
-
li:nth-child(odd)：在父元素全部子节点中，取第 1、3、5… 位，且该位必须是li -
li:nth-of-type(odd)：先提取所有li，再从中取第 1、3、5… 个 —— 它们在 DOM 中的位置可能是第 2、7、11 位
典型陷阱：表格行斑马纹用 tr:nth-child(odd) 看似合理，但如果 tbody 里混了 tr class="summary" 或服务端注入的 tr（如广告行），条纹就会错位。此时应改用 tbody > tr:not([class]):nth-of-type(odd) 或直接加 class 控制。
调试时怎么一眼看出该用哪个
别靠背规则，用 DevTools 实时验证：
- 在 Styles 面板临时加一条
div:nth-child(3) { outline: 2px solid red; }，看红框套住谁；再换成div:nth-of-type(3)，对比差异 - 右键目标元素 →「Scroll into view」，展开父节点，数清它前面有多少个 Node —— 包括灰色的
#text和#comment - 把相邻同类型标签临时改成其他标签（比如把
p改成section），观察nth-of-type是否失效 —— 如果失效，说明你误以为它“跨类型计数”
最常被忽略的一点：自定义元素如 my-card 和 My-Card 在严格模式下被视为不同类型，my-card:nth-of-type(1) 不会匹配后者；而大小写混用的原生标签（如 P 和 p）在 HTML 中等价，但在 XHTML 或 XML 上下文中可能不兼容。
