nth-child(n) 按父元素所有子节点（含注释、空白文本等）的物理顺序计数，而非仅li标签；常用替代方案是nth-of-type(n)，它只统计同类型元素。
nth-child(n) 为什么总是数错位置
它不是按“你写的第几个 li”来算，而是按父元素下**所有子节点的物理顺序**从 1 开始数——包括 <div>、<p>、HTML 注释 <!-- -->，甚至换行缩进产生的空白文本节点。哪怕你看不到，浏览器也把它当一个子节点。
常见现象：li:nth-child(2) 没生效，实际是因为父 <ul> 第一个子节点是注释，第二个是 <h3>，第三个才是 <li>，那它真正对应的是 li:nth-child(3)。
- 用开发者工具选中父元素 → 展开子节点列表，逐个数（右键 → “Reveal in Elements panel” 可快速定位）
- 临时加
* { outline: 1px solid red; }，直观看每个子节点边界和顺序 - 删掉注释、把 HTML 写成单行（如
<ul><li>A</li><li>B</li></ul>），再验证是否“突然就对了”
nth-child 和 nth-of-type 混用导致目标漂移
li:nth-child(2) 和 li:nth-of-type(2) 完全不是一回事：前者要求“父元素第 2 个子元素必须是 <li>”，后者只要求“父元素下第 2 个 <li>”。中间夹了其他标签，两者结果立刻分叉。
例如结构：<ul><div>intro</div><li>first</li><p>note</p><li>second</li></ul>
立即学习“前端免费学习笔记（深入）”；
-
li:nth-child(2)→ 匹配第一个<li>（它是第 2 个子元素） -
li:nth-child(4)→ 匹配第二个<li>（它是第 4 个子元素） -
li:nth-of-type(2)→ 匹配第二个<li>（不管前面有多少非<li>元素）
绝大多数场景下，你要的其实是后者——别硬扛 nth-child，直接换 nth-of-type 更稳。
嵌套层级写错，选择器根本没作用到目标上
写 .nav a:nth-child(2)，本意可能是想选导航里第二个链接，但实际匹配的是「某个 <a> 元素，它同时满足：是其父元素的第 2 个子元素，且 class 为 nav 的祖先下」——而这个 <a> 很可能根本不在 .nav 直接子级里。
- 先单独测试
.nav > a是否能命中目标，确认层级关系 - 如果
<a>套在<li>里，就该用.nav > li:nth-child(2) > a，而不是往a上套nth-child -
span:nth-child(1)在每个<li>里都成立（因为每个<li>下只有一个<span>），永远不会有span:nth-child(2)
动态渲染后 DOM 结构已变，但 CSS 还按旧序号算
React 或 Vue 中用 v-if / {condition && <div>} 控制显隐时，元素可能被完全移除；display: none 不影响计数，但 remove() 或条件插入会改变真实子节点数量。
- 刷新页面后打开 Elements 面板，手动检查目标元素当前在父节点下的实际位置和索引
- 关键逻辑（比如“只显示前 3 条”）别全靠
nth-child，JS 渲染时主动加class="is-first"或data-index="2"更可控 -
li:nth-child(-n+3)看起来能选前 3 个，但如果中间某条被 JS 移除，它就自动变成选剩余的前 3 个——行为可能偏离预期
最麻烦的从来不是语法写错，而是你坚信 DOM 是干净线性结构，而它早已被注释、空格、框架 wrapper 和条件渲染悄悄改写了。
