nth-child匹配父元素下同级所有子元素中的第N个，而非第N个目标类型元素；如li:nth-child(2n)失效，常因第2、4等位置实际是div或文本节点。
nth-child公式怎么写才不选错元素
直接说结论：nth-child匹配的是父元素下**同级所有子元素中的第N个**，不是“第N个
li:nth-child(2n)却没生效，是因为第二个子元素根本不是li——可能是div、注释、文本节点，甚至空格换行（在HTML中也算文本节点）。实操建议：
- 先用浏览器开发者工具检查目标元素的「实际兄弟节点顺序」，右键 → “Edit as HTML”，看它前面有多少个节点（包括
<!-- 注释 -->、<br>、换行符生成的TextNode） - 公式
an+b中，a是周期，b是偏移（从1开始计数），n从0开始代入；例如3n+1对应第1、4、7、10…个子元素 - 别用
nth-child(odd)代替nth-child(2n+1)——虽然结果一样，但前者可读性差，且部分老版本Safari对关键词支持不稳定 - 如果父容器里混有多种标签，优先考虑
nth-of-type，它只算同类型兄弟元素
nth-child(2n)和nth-of-type(2n)区别在哪
这是最常混淆的一对。假设HTML是：
<ul> <div>header</div> <li>A</li> <li>B</li> <p>note</p> <li>C</li> </ul>那么
li:nth-child(2n)一个都选不到——因为第2、4个子元素分别是<li>B</li>和<p>note</p>，后者不是li，不满足“第2n个子元素是li”这个条件。
而li:nth-of-type(2n)会选中B和C：它忽略其他类型，只在所有li中按顺序取偶数位（第2、第4个li，这里只有3个li，所以只选第2个即B，第4个不存在）。
使用场景：
立即学习“前端免费学习笔记（深入）”；
- 结构干净、全是同类型标签（如纯
li列表）→nth-child更直觉 - 结构含插件、广告位、描述块等杂项 →
nth-of-type更可靠 - 需要兼容IE8及更早版本 → 二者都不支持，得用class模拟
为什么nth-child(n+3)能跳过前两项
n+3的意思是：当n=0时取第3个，n=1取第4个，n=2取第5个……所以它从第3个子元素开始连续选中后面所有。这不是“排除前两个”，而是“从第3个起，每个都选”。
常见错误现象：
- 写成
nth-child(3n)想跳过前两个——结果是选3、6、9…，中间全空着 - 写成
nth-child(n+2)以为能从第2个开始，但若第2个不是目标元素类型，照样不生效 - 在Flex或Grid布局中，DOM顺序和视觉顺序不一致时，
nth-child仍按DOM顺序计算，不会按渲染位置变
性能影响很小，但过度嵌套选择器（如ul > li:nth-child(2n+1) > a > span）会拖慢CSS解析，建议控制在3层以内。
移动端iOS Safari里nth-child失效怎么办
不是失效，是触发了iOS Safari的一个老bug：当父元素用display: flex或display: grid，且子元素存在visibility: hidden或display: none时，nth-child可能把隐藏元素也计入序号，导致预期错位。
解决方法很具体：
- 改用
nth-of-type（只要类型一致，它天然忽略display: none的元素） - 把隐藏逻辑从
display: none换成opacity: 0; pointer-events: none，保持DOM参与计数但视觉不可见 - 避免在flex容器里混用
display: none和nth-child，尤其在iOS 14.5以下版本 - 真要兼容极旧环境，就老老实实用
class="item-1 item-2 item-3"配合JS动态加类
真正麻烦的是那些看不见的空白文本节点——它们在HTML源码里藏得深，又确确实实影响nth-child的计数，调试时最容易漏掉这一层。
