nth-child易失效因文本/注释节点干扰、与nth-of-type混淆、动态渲染导致DOM偏移、选择器层级错误；应检查真实子节点、优先用nth-of-type或JS控制序号。
父元素里混着文本节点或注释，nth-child 就会数错
浏览器把空格、换行、HTML 注释（<!-- -->）全算作子节点，哪怕你看不到。比如这段结构：
<ul> <li>第一项</li> <li>第二项</li> <!-- 备注 --> <li>第三项</li> </ul>
此时 li:nth-child(3) 匹配不到“第三项”，因为第 3 个子节点是注释，不是 <li>；真正匹配的是 li:nth-child(4)。
- 用开发者工具选中
<ul>，展开看所有子节点，确认目标<li>真的是第 n 个子节点 - 临时加样式
* { outline: 1px solid red; }，直观看到每个子节点的边界和顺序 - 删掉注释或把 HTML 写成单行（
<ul><li>...</li><li>...</li></ul>），再测试是否“突然生效”
nth-child 和 nth-of-type 混用导致误判
你写的是 p:nth-child(2)，但想要的是“第二个 <p>”，这俩根本不是一回事。
-
p:nth-child(2)：要求父元素的第 2 个子元素**必须是<p>** -
p:nth-of-type(2)：只要父元素下有至少 2 个<p>，就选第 2 个，不管中间夹了几个<div>或<h2> - 如果结构不干净（CMS 输出、Vue 渲染插入 comment 节点），优先试
nth-of-type，它更贴近语义直觉
动态渲染后 DOM 位置偏移，nth-child 还按旧序号匹配
React/Vue 中用 v-if 或 {condition && <div>} 控制元素显隐时，DOM 节点可能被完全移除或插入 wrapper，导致原定的第 4 个子元素变成第 6 个。
立即学习“前端免费学习笔记（深入）”；
-
display: none不影响nth-child计数，但remove()或条件渲染会改变真实子节点数量 - 检查 DevTools 的 Elements 面板，刷新后看目标元素是否还在预期位置
- 关键逻辑（如“只显示前 3 条”）别全靠 CSS，JS 渲染时主动加
class="is-hidden"更可控
伪类写在错误层级，根本没机会匹配
常见低级错误：div .item:nth-child(2) 想选 class 为 item 的第二个子元素，但实际匹配的是「某个 <div> 下，它的第二个子元素且带 item 类」——而那个子元素很可能不是 <div>。
- 确认选择器主干是否对应你要操作的元素类型，例如想控制
<li>，就该从li:nth-child(n)开始写 - 避免嵌套过深，比如
.list > li:nth-child(2) span，先确保.list > li:nth-child(2)能单独命中 - 用 DevTools 的 “Computed” 面板看样式是否被划掉，若被划掉，大概率是选择器没命中目标元素本身
实际项目里最麻烦的不是语法写错，而是你以为 DOM 是干净的线性结构，结果它早被框架、模板引擎或 CMS 塞进了看不见的节点。调试时别跳步，先看真实子节点树，再决定用 nth-child 还是 nth-of-type，或者干脆让 JS 来管序号。
