:nth-child(n+k)按所有子节点（含文本、注释）计数，非仅目标标签；应优先用:nth-of-type()选同标签序号，或用data-index/js打标规避dom结构依赖。
nth-child(n+k) 选不到预期元素？检查索引起点和兄弟节点类型
它只认同级、同标签（严格说同“元素节点”）的顺序位置，不是页面里第几个 <div> 或第几个“可见块”。比如父容器里混着 <code><p></p>、<span></span>、注释、文本节点，它们全算进计数——<span></span> 是第 2 个子节点，那它就可能是 :nth-child(2)，哪怕你只想选 <div>。
<p>常见错误现象：<code>div:nth-child(2n) 没生效，或选中了不该选的非 div 元素。
- 用
:nth-of-type()替代，如果目标只是同标签下的序号（比如“所有div中的偶数个”） - 确保父元素下没有意外插入的文本节点（比如换行、空格），可用
display: contents或 JS 清理，但更推荐结构上避免 - 调试时用浏览器开发者工具的“Elements”面板，右键 → “Break on > Attribute modifications”，观察实际 DOM 子节点构成
写 n+3 还是 3n+1？搞清公式对应的实际范围
:nth-child(n+3) 表示从第 3 个开始往后全选（3,4,5,…），而 :nth-child(3n+1) 是每 3 个取 1 个（1,4,7,10,…）。很多人混淆“起始偏移”和“周期步长”。
使用场景：做列表分页高亮、表格隔行变色延后两行、卡片流中跳过前两张再样式化。
立即学习“前端免费学习笔记（深入）”；
-
n+1等价于all（从第一个起全选），但语义更明确，兼容性一致 -
-n+5是倒序选前 5 个（5,4,3,2,1），常用于“最后几项特殊处理”，但要注意父节点总数是否 ≥5 - 负系数如
-2n+7容易算错，建议先代入n=0,1,2手动验算结果集
IE8 及更老浏览器不支持？别硬扛，用 class 降级更稳
IE8 及以下完全不识别 :nth-child()，连带影响所有依赖它的 CSS 选择器。不是加个 polyfill 就能解决——CSS 选择器解析在 IE8 是纯静态匹配，无法动态重算节点序号。
性能影响：现代浏览器对 :nth-child() 优化很好，但若配合复杂嵌套（如 article > section > div:nth-child(2n+1) p:last-child），重排重绘时计算开销略升，不过一般感知不到。
- 服务端渲染或构建时，给目标元素直接加
class="nth-2"、class="nth-odd"等语义类，CSS 写死规则 - JS 动态打标（如用
querySelectorAll+forEach遍历加 class），仅在必要时触发，避免首屏阻塞 - 不要用
@supports (selector(:nth-child(1)))包裹整段样式——IE8 不认识@supports，会直接丢弃整个规则块
和 :nth-of-type() 混用时，DOM 结构稍变就失效
两者逻辑根本不同：:nth-child() 数的是所有子节点位置，:nth-of-type() 只数同标签名的兄弟。一旦中间插入一个 <div> 或删掉一个 <code><p></p>，前者序号全乱，后者可能不变。
容易踩的坑：用 :nth-child(2) 选第二个内容区块，结果运营后台加了个 <aside></aside> 插槽，样式立刻错位。
- 如果结构稳定、且必须按视觉流序号控制（比如“第三张 banner 下方加分割线”），优先用 JS 计算并加 class，而非纯 CSS
- 用
data-index属性标记逻辑序号（如<section data-index="3"></section>），再写[data-index="3"]选择器，完全脱离 DOM 位置依赖 - 审查工具里对比
$0.parentElement.children和$0.parentElement.querySelectorAll('p')的 length 差异，就能快速判断该用哪个伪类
真正麻烦的不是公式怎么写，而是你没法靠看 HTML 源码确定最终生效的节点——得打开 DevTools 看实时 DOM 树，数清楚那些看不见的文本节点和注释到底占了几个“child”的坑。
