:nth-child不会失效，它只按DOM子节点物理顺序匹配，不响应动态变化；JS插入、空格文本节点、框架注释等都会改变索引导致错位；应改用JS动态加类或内联样式替代。
它根本不会“失效”，只是你写的序号和 DOM 实际位置对不上了。 :nth-child 从不响应动态变化——它只认当前 DOM 树里子节点的物理顺序，插入、删除、显隐都不会触发它“重算”。你看到的错位，是序号偏移导致的必然结果。
为什么 JS 插入后样式全乱了
插入新元素会改变原有元素在父容器中的子节点索引，而你的 CSS 规则没跟着变。
- 比如原
<ul> <li>A</li> <li>B</li> </ul>，li:nth-child(2)匹配 B；JS 在开头prepend一个新<li>X</li>后，B 变成第 3 个子节点，nth-child(2)就匹配不到它了 - 用
innerHTML +=追加时，若父容器里有换行或空格，它们会作为文本节点计入计数，导致目标<li>实际是第 4、6、8…个子节点，而非你预期的第 4、5、6… - Vue/React 渲染后可能插入注释节点（如
<!--v-if-->）或 wrapper<div>，让原本第 2 个 <code><li>变成第 5 个子节点为什么“强制重绘”解决不了问题
调
el.offsetHeight或getComputedStyle只会让浏览器重新计算样式，但:nth-child的计数逻辑完全不变——它始终基于 DOM 顺序，不是可见顺序或业务顺序。- 哪怕你把所有非
<li>节点都设为display: none，它们依然参与计数 -
:nth-of-type看似更稳，但它只按标签名计数，无法解决混合结构（比如<li>中夹着<div class="separator">），且同样受动态插入影响 <li>所谓“触发重排重绘”是治标不治本，属于误把语义问题当渲染 bug 处理</li> <h3>真正该怎么做：绕过 nth-child，用 JS 控制序号</h3> <p>动态场景下，把序号控制权交还给 JS，比硬扛 CSS 伪类更可靠。</p> <ul> <li>每次插入/删除后，执行 <code>document.querySelectorAll('ul li')，遍历并按index % 2 === 0手动添加row-even/row-odd类 - 用
MutationObserver监听父容器的childList变化，自动重跑上述逻辑，覆盖异步插入（如分页加载、拖拽排序） - 如果只是临时样式，直接写
el.style.backgroundColor = index % 2 ? '#fff' : '#f5f5f5'，跳过选择器层，零延迟、零干扰
最容易被忽略的是：你写的
:nth-child(2)并不表示“第二个<li>”，而是“父元素下第 2 个子节点，且恰好是<li>”。只要中间混进一个文本节点、注释或其它标签，它就断了——这不是 bug，是设计如此。 - 哪怕你把所有非
