an+b中n从0开始计算，如3n+1匹配第1、4、7…个子元素；:nth-child()按父元素所有子元素计数，非目标节点会干扰序号；应优先用:nth-of-type()或-n+n限定范围，避免依赖2n等不兼容写法。
an+b 公式里 n 是从 0 开始算的，不是从 1
很多人写 3n+1 时下意识以为“第 1、第 4、第 7…”是从 n=1 开始代入，结果发现样式没生效——其实是浏览器用 n=0,1,2,… 迭代计算：n=0 得到 1，n=1 得到 4，n=2 得到 7。只要 an+b > 0，该位置就命中。
常见错误是把 2n+2 当成“偶数位”，但它实际匹配的是第 2、4、6…（没错），而 2n 却不匹配任何元素——因为 n=0 时得 0，n=1 时得 2，但位置必须 ≥1，所以 2n 等价于 2n+2？不对：2n 在 CSS 中被当作 2n+0，而 0 不合法，因此浏览器会忽略该规则或直接不匹配。真正安全的写法是 2n+2 或更常见的 2n 实际上被多数浏览器兼容处理为 2n+0 → 自动跳过 n=0，从 n=1 起算。但别依赖这个：明确写 2n+2 更可靠。
-
3n+1→ 匹配第 1、4、7、10…（n=0,1,2,3…） -
3n-1→ n=0 得 -1（跳过），n=1 得 2，n=2 得 5，n=3 得 8 → 实际匹配第 2、5、8… -
-n+5→ n=0→5，n=1→4，n=2→3，n=3→2，n=4→1，n=5→0（停）→ 匹配第 1~5 项
为什么 li:nth-child(3n+1) 有时选不到第一个 li
因为 :nth-child() 计数的是父元素下的所有子元素，不分标签类型。如果父容器开头有 div、p 或注释节点，那第一个 li 可能是第 3 个子元素，3n+1 就不会命中它（除非它恰好在第 1、4、7…位）。
例如：
- item 1
- item 2
note
此时 li:nth-child(3n+1) 完全不生效——第一个 li 是第 3 个子元素，3n+1=3 → 需要 n=2/3，但 n 必须是整数，3n+1=3 ⇒ n=2/3 ❌。真正能命中的只有当位置满足公式解为整数 n ≥ 0。
- 想按
li自身顺序选第 1、4、7…个？改用li:nth-of-type(3n+1) - 不确定父元素有没有杂项子节点？先用浏览器开发者工具的“Computed”面板看该
li的nth-child实际序号 - 需要稳定控制前 N 个？优先用
-n+N，比如li:nth-child(-n+3)保底选前三个
a 为负数时，-an+b 不是倒序取倍数，而是限定范围
-3n+10 不代表“从末尾每 3 个取一个”，而是解不等式 -3n+10 ≥ 1，得 n ≤ 3，所以 n=0,1,2,3 → 位置为 10,7,4,1。它选的是离开头较近的几个点，不是从结尾扫描。
真正从结尾倒数要用 :nth-last-child()，比如 li:nth-last-child(2) 才是倒数第二个 li。
-
-n+5和:nth-last-child(-n+5)完全不同：前者选前 5 个，后者选后 5 个 -
a为负时，b必须足够大，否则无匹配（如-5n+2：n=0→2，n=1→-3 → 只有第 2 个） - 性能上无差异，但语义混乱——除非明确要“前 N 个”，否则少用负 a
odd/even 是语法糖，但和 2n+1/2n 不完全等价
odd 等价于 2n+1，even 等价于 2n+0（即 2n）。但部分老版本 Safari 对 2n 支持不稳定，而 even 兼容性更好。
另外，even 比 2n+2 更直观——后者漏掉第 2 个之前的偶数位（其实没有，2n+2 从第 2 开始），但理解成本高。
- 隔行变色首选
tr:nth-child(even)，别写2n或2n+2 - 不要混用：比如
li:nth-child(odd), li:nth-child(2n+1)同时写，纯属冗余 -
odd/even不支持 IE8 及更早版本；如需兼容，用:first-child+:nth-child(2n)组合降级
TextNode），也会让所有 :nth-child 的序号偏移。调试时第一反应不该是“公式写错了”，而是打开 Elements 面板，数一数那个元素在父节点下的真实子元素索引。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
