:nth-child(n) 中的 n 是自然数序列而非索引，它匹配父元素下第 n 个子元素（无论类型），不跳过不匹配节点；真正选“第 n 个某类型元素”应使用 :nth-of-type(n)。
nth-child(n) 的 n 不是索引，是自然数序列
很多人写 div:nth-child(2) 想选第二个 div，结果没生效——因为 :nth-child(n) 看的是父元素下第 n 个子元素是否匹配选择器，不是“第 n 个匹配的元素”。它不跳过不匹配的兄弟节点。
比如：
<ul> <li>标题</li> <p>一段说明</p> <li>第一项</li> <li>第二项</li> </ul>此时
li:nth-child(2) 完全不匹配，因为第 2 个子元素是 <p></p>，不是 li；li:nth-child(3) 才匹配第一个 li（“第一项”）。
- 真正想选“第 n 个
li”，该用:nth-of-type(n) -
:nth-child(2n)表示第 2、4、6…个子元素，不管类型；:nth-of-type(2n)表示第 2、4、6…个li元素（跳过中间的p、span等） - 公式里
n从 0 开始代入：比如2n+1→ n=0 得 1，n=1 得 3，n=2 得 5……所以是奇数位
写等差数列公式时，系数和常数必须是整数
CSS 规范只接受整数系数和整数偏移量，2.5n+1 或 n+0.5 会被整个声明忽略，浏览器根本不解析。
立即学习“前端免费学习笔记（深入）”；
常见错误现象：div:nth-child(1.5n) 在 DevTools 里直接灰掉，控制台无报错，但样式不生效。
- 合法公式：
3n、3n+1、3n-2、-n+5 - 非法公式：
1.5n+2、n/2、n+0.3、sqrt(n) -
-n+5等价于 “倒数第 5 个起，往前每 1 个选 1 个”，即匹配第 5、4、3、2、1 个子元素（n≥0 时结果 ≥1 才有效）
nth-child 和 flex/grid 顺序不一致时会出人意料
当容器用了 display: flex 或 grid，且设置了 order 属性，视觉顺序和 DOM 子元素顺序就可能不同——而 :nth-child() 只认 DOM 顺序，不看 order 或视觉排列。
例如：
<div class="list"> <div style="order: 2">B</div> <div style="order: 1">A</div> <div style="order: 3">C</div> </div>DOM 中第一个子元素仍是 B，所以
div:nth-child(1) 匹配的是 B，不是视觉上最左的 A。
- 如果要按视觉顺序选（比如“第 2 个显示出来的 item”），不能依赖
:nth-child()，得用 JS 或改用语义化结构（如把排序逻辑移到数据层） - flex 容器里用
:nth-child()做隔行变色，只要没动order就没问题；一旦有order，颜色就会“错位” - Grid 中同理，
grid-area或grid-row不影响:nth-child()计算
兼容性与性能：老浏览器和超长列表下的隐性代价
:nth-child() 在 IE9+ 和所有现代浏览器都支持，但 IE8 及更早版本完全不识别，连降级都不触发——如果项目还要兼容 IE8，得用类名（如 .item-odd）或 JS 动态加 class。
性能上，浏览器对 :nth-child() 的实现通常做了优化，但极端场景仍有隐患：
- 在含几千个子元素的容器里用
:nth-child(1000n)，虽然只匹配少量元素，但浏览器仍需遍历全部子节点判断位置，可能卡顿 - 动态插入/删除大量节点后频繁重排，
:nth-child()触发的样式重计算开销比基于 class 的方案略高 - 服务端渲染（SSR）时若 HTML 已带
:nth-child样式，客户端 hydration 后无需 JS 干预；但若靠 JS 补 class，则多一次 DOM 遍历
真正难的不是写出公式，而是意识到：它定位的是“结构位置”，不是“呈现序号”，也不是“数据索引”。一旦混淆这三者，调试时花的时间远超写样式本身。
