:nth-child严格按DOM子节点物理顺序计数，display:none元素仍参与计数；:nth-of-type仅统计同标签名节点但无法忽略隐藏元素；可靠方案是JS动态添加data-visible-index属性并配合CSS使用。
:nth-child 从不“错位”，它只是严格按 DOM 子节点物理顺序计数，而你插入的隐藏元素（display: none）仍算一个子节点——序号必然偏移。
为什么 display: none 的元素仍参与 :nth-child 计数
浏览器解析 :nth-child(n) 时，只遍历父元素的 childNodes 列表，逐个检查索引位置（从 1 开始），完全不读取 getComputedStyle(el).display。哪怕元素被 display: none、visibility: hidden 或 opacity: 0 隐藏，只要它还在 DOM 树里，就计入总数。
- 原始结构：
<ul><li>A</li><li>B</li></ul>→li:nth-child(2)匹配 B - 插入隐藏项：
<ul><li>A</li><li style="display:none">H</li><li>B</li></ul>→ B 变成第 3 个子节点，:nth-child(2)现在匹配不到任何li - 注释、换行、
<script>标签同理：它们都是childNodes中的有效节点，都会挤占序号
:nth-of-type 能解决这个问题吗
不能彻底解决，但比 :nth-child 更鲁棒——它只统计同标签名的兄弟节点，跳过 <div>、<p> 等干扰项。
- 适用场景：表格中混有
<thead>、<tbody>或广告<div class="ad">，用tr:nth-of-type(2)至少能避开非tr节点 - 局限：仍会把
display: none的<tr>算进去，因为 DOM 节点未被移除 - 误用风险：若目标容器内有多个标签类型（如
<li>和<li class="separator">），li:nth-of-type(2)仍可能选错——它不区分 class
真正可靠的动态处理方案
放弃让 CSS 伪类响应运行时状态，把序号控制权交还给 JS。
立即学习“前端免费学习笔记（深入）”；
- 每次插入/过滤后，执行
document.querySelectorAll('tbody tr')，遍历可见项并添加data-visible-index="1"、data-visible-index="2"等属性，再用tr[data-visible-index="odd"]写样式 - 用
MutationObserver监听childList变化，自动触发重标序号，覆盖分页加载、拖拽排序等异步场景 - 临时需求可直接操作
el.style：trEl.style.backgroundColor = index % 2 ? '#fff' : '#f5f5f5'，零延迟、零选择器干扰 - 框架内（Vue/React）优先用
v-if/{show && <tr>}彻底移除节点，而非v-show或style={{ display: 'none' }}
最容易被忽略的是：你写的 :nth-child(2) 不表示“第二个可见 li”，而是“父元素下第 2 个子节点，且恰好是 li”。中间插一个空格、注释或隐藏 <li>，它就断了——这不是 bug，是设计如此。
