nth-child失效主因是误将“第n个目标元素”理解为“第n个子节点”，实际需确保目标元素恰好位于父元素第n个子节点位置，而文本、注释、其他标签均会干扰序号。
直接说结论：nth-child 失效，90% 是因为你本意想“选第 n 个 p”，却写了 p:nth-child(n)——它实际要求“第 n 个子节点必须是 p”，而 DOM 中往往夹着文本、注释或别的标签。
为什么 p:nth-child(2) 常常不生效
浏览器数的是父元素下所有子节点顺序：标签、换行空格（文本节点）、<!-- 注释 --> 都算一个位置。哪怕你只写了两个 p，只要前面有 <h2></h2> 或 HTML 换行产生的空白，p 就不是第 2 个子节点。
- 用开发者工具右键目标
p→ “Reveal in Elements panel”，看它在父元素下的真实序号（注意：#text节点会显示为换行或空格） -
p:nth-child(2)只会匹配“第二个子节点恰好是p”的场景；如果第二个是#text，整条规则就匹配不到任何元素 - Vue/React 渲染后自动插入的
<!--v-if-->或 wrapperdiv，会让手写时有效的nth-child突然失效
nth-of-type 什么情况下能立刻解决问题
当你真正关心的是“第几个 li”“第几个 tr”，而不是“坐在第几个座位上的 li”，就该切到 nth-of-type。它自动过滤出同标签兄弟再编号，完全无视中间插了多少 div、span 或空格。
-
li:nth-of-type(3)在<ul> <li>A</li> <div>sep</div> <li>B</li> <li>C</li> </ul>中稳稳命中第三个li（即 C），而li:nth-child(3)会命中div（因为它才是第 3 个子节点） - 富文本编辑器输出、CMS 生成的 HTML、表单字段组等混排结构，优先试
nth-of-type - 注意：
div.red:nth-of-type(odd)合法，但div:nth-of-type(odd).red无效——伪类必须紧跟在标签名后
动态插入或显隐后 nth-child 错乱怎么办
JS 插入新 li 或用 display: none 隐藏某些 tr，不会让 nth-child 重排索引。它永远按完整 DOM 树计数，和“是否可见”“是否刚插入”无关。
立即学习“前端免费学习笔记（深入）”；
- 别试图用
el.offsetHeight或getComputedStyle“触发重绘”来修复——这改不了计数逻辑 - 表格过滤场景下，隐藏行仍参与
:nth-child(odd)计算，导致斑马纹错位；正确做法是 JS 遍历当前可见行，手动加row-odd/row-even类 - 长期方案：用
MutationObserver监听父容器子节点变化，自动重跑类名分配逻辑，避免漏掉异步插入
最容易被忽略的一点：哪怕你把非目标节点设成 display: none 或 visibility: hidden，它们依然计入 nth-child 序号。DOM 位置和视觉状态是两回事，不能靠 CSS 显隐来“腾出座位”。
