:nth-child索引从1开始是w3c标准明确规定，非浏览器差异；公式中n从0代入，但只保留结果≥1的位置，语义上对应自然计数，与dom的0-based索引本质不同。
nth-child 的索引从 1 开始是 CSS 规范的明确约定
不是浏览器实现差异，也不是历史遗留，而是 W3C 标准白纸黑字规定：:nth-child(n) 中的「第 n 个」指人类自然计数意义上的位置——第一个子元素就是第 1 个，没有「第 0 个子元素」这个概念。所有主流浏览器（Chrome、Firefox、Safari、Edge）都严格遵循这一定义。
公式里的 n 才是从 0 开始代入计算的
容易混淆的点在于公式写法 an+b 中的变量 n：它只是一个数学占位符，浏览器会自动用整数 n = 0, 1, 2, 3... 代入，但只保留结果 ≥ 1 的那些值作为最终匹配位置。
-
:nth-child(2n)→ 代入得 0, 2, 4, 6... → 实际匹配第 2、4、6... 个子元素（跳过 0） -
:nth-child(2n+1)→ 代入得 1, 3, 5, 7... → 匹配第 1、3、5... 个子元素 -
:nth-child(-n+3)→ 代入得 3, 2, 1, 0... → 只取 1/2/3，即前三个子元素
这里的 n 是循环计数器，和 DOM 索引无关；真正起作用的是算式结果，且结果必须 ≥ 1。
为什么不用 0-based？因为语义和 DOM API 不一致
CSS 选择器面向的是文档结构和视觉表达，不是编程接口。对比来看：
-
document.children[0]是 JS 的数组索引，0-based —— 这是程序访问视角 -
:nth-child(1)是样式规则，1-based —— 这是排版与设计视角 - 如果改成 0-based，
:nth-child(0)就要匹配「不存在的位置」，违反选择器必须指向真实元素的基本前提
更实际的问题是：HTML 中 first-child、last-child 这些关键词天然对应 1-based 语义，强行统一成 0-based 会导致语义断裂。
容易踩的坑：混用 DOM 索引和 nth-child 计数
开发者常在调试时用 JS 查 el.parentElement.children.length 或 Array.from(el.parentElement.children).indexOf(el)，误以为这个索引可以直接套进 :nth-child()。但要注意：
-
children只包含元素节点，而:nth-child()计数包含所有子节点（文本、注释等）——不过现代浏览器对空白文本节点基本忽略，所以多数情况下数值一致 - 如果父元素里有
<script></script>或<style></style>标签，它们会被计入:nth-child()的总数，但不会出现在children列表中 - 最稳妥的验证方式是用浏览器开发者工具的「Computed」面板看「Matches selector」，或临时加
* { outline: 1px solid red; }辅助观察顺序
真正复杂的点从来不在公式本身，而在于你是否清楚当前父容器里到底有多少个「参与计数的子节点」——尤其当模板由框架动态生成、中间插入了注释或条件占位符时。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
