:nth-child(n)匹配父元素下第n个子节点且类型必须一致；换行、注释、其他标签会干扰序号，:nth-of-type(n)仅统计同名标签更稳定；动态插入需手动重算或监听mutationobserver。
它根本不是“选第几个元素”，而是“选父元素下第几个子节点，且那个位置上恰好是你写的标签”——只要中间混进一个文本节点、注释或别的标签，就断了。
为什么 li:nth-child(2) 明明写了却没变色？
你数的“第二个 li”，在 DOM 树里很可能不是父元素的第二个子节点。HTML 换行缩进产生的空格、回车会生成 Text 节点；<!-- comment --> 是注释节点；插个 <div class="ad"> 就会让后续所有 <code>li 的索引 +1。浏览器开发者工具里右键父元素 → “Edit as HTML”，才能看清真实子节点顺序——别只看折叠后的 Elements 面板。
-
li:nth-child(2)匹配失败，大概率是因为第 2 个子节点是<p></p>或注释，不是<li> - 结构含 CMS 输出、用户编辑区、广告位时，
nth-child几乎必然错位 - Flex/Grid 布局下视觉顺序 ≠ DOM 顺序，而
:nth-child只认后者
li:nth-of-type(2) 真的更稳吗？
是的，但有前提：nth-of-type 只统计同名标签（比如所有 li），跳过 div、p、注释等干扰项。它不解决混合结构中夹着 <div class="separator"> 的问题，但能避开换行、注释这类隐形干扰。<ul>
<li>纯 <code><ul><li>...</li></ul> 结构下，nth-child 和 nth-of-type 效果一致
.item:nth-of-type(2) 是无效语法——伪类必须紧跟标签名，不能跟 classnth-of-type，但现代项目基本无需考虑动态插入元素后 :nth-child 全乱了，怎么办？
:nth-child 从不响应变化——它只按当前 DOM 物理顺序匹配。JS 插入新节点、Vue/React 渲染注入注释节点、innerHTML += 带来的文本节点，都会让原有元素索引偏移。所谓“强制重绘”（如读取 offsetHeight）完全无效，因为计数逻辑根本不依赖渲染状态。
- 每次插入/删除后，用
document.querySelectorAll('ul li')遍历，按index手动加row-1、row-2类 - 监听
MutationObserver的childList变化，自动重跑序号逻辑 - 临时样式直接写
el.style.backgroundColor = ...，跳过选择器层，零延迟
公式 an+b 怎么写才不踩坑？
n 从 0 开始代入，但结果序号必须 ≥ 1 才有效。nth-child(0) 和 nth-child(-1) 永远不匹配。不要背口诀，记住：起点由 +b 决定，步长由 a 决定。
-
3n+1匹配的是第 1、4、7、10… 个子元素，不是“每 3 个取第 1 个” - 选前 5 个？
:nth-child(-n+5)可行，但不如显式写:nth-child(1), :nth-child(2), ..., :nth-child(5)直观 - 选第 4 到第 8 个？必须组合：
:nth-child(n+4):nth-child(-n+8)，缺一不可
最常被忽略的一点：你写的 :nth-child(2) 并不表示“第二个”，而是“父元素下第 2 个子节点，且恰好是 li”。只要这个位置被占了，它就失效——这不是 bug，是设计如此。
