nth-child基于DOM静态位置索引，不响应动态插入、显隐或重排；JS插入新元素会改变原有元素序号，导致样式错位，需手动重置类名或用MutationObserver监听更新。
nth-child 计数不会随 DOM 动态插入自动更新
nth-child 是纯结构型伪类，它在样式计算时只读取当前 DOM 树中子元素的**静态位置索引**，不监听增删、显隐或重排。JS 插入新元素后，浏览器会重新触发样式计算（reflow + repaint），但 nth-child 的匹配逻辑本身不变——它仍按「父元素下所有子节点的原始顺序」重新计数，而不是“把新元素插进去再重排序号”。所以你看到的“失效”，其实是新元素插入后，原有元素的索引发生了偏移，而你的 CSS 规则没适配这个变化。
常见动态插入场景下 nth-child 失效的表现
-
ul原有 3 个li，li:nth-child(odd)正常给第 1、3 个上色；JS 在开头prepend一个新li后，原来第 1 个变成第 2 个，第 3 个变成第 4 个 → 全部脱离odd匹配 - 用
innerHTML += '<li>new</li>'追加，但父容器里存在文本节点（如换行、空格），导致新li实际是第 2、4、6…个子节点，而非预期的第 4、5、6… - Vue/React 渲染后插入了注释节点（
<!--v-if-->）或 wrapperdiv，使目标元素的nth-child(n)索引与手写 HTML 时完全不同
不依赖重绘，直接修复 nth-child 逻辑错位
别指望“强制重渲染”能修好 nth-child —— 它不是渲染 bug，是语义误用。真正可靠的做法是切换到可被 JS 控制的 class 管理：
- 每次插入/删除后，遍历当前所有目标元素（如
document.querySelectorAll('ul li')），用index % 2 === 0判断奇偶，手动添加row-even/row-odd类 - 用
MutationObserver监听父容器的子节点变化，自动重跑上述逻辑，避免漏掉异步插入 - 如果只是临时加样式，直接用
el.style.backgroundColor = index % 2 ? '#fff' : '#f5f5f5'，绕过 CSS 选择器层
为什么不用 :nth-of-type 或 CSS 自动修复？
:nth-of-type 看似更“智能”，但它只对同标签计数，无法解决混合结构问题（比如 li 中夹着 div.separator），且同样受动态插入影响；而所谓“触发重绘”（如 el.offsetHeight、getComputedStyle）只会让浏览器重新计算样式，但不会改变 nth-child 的底层计数逻辑——它始终基于 DOM 顺序，不是基于可见顺序或业务顺序。
dmap-jsapi-skill
下载
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
真正容易被忽略的是：哪怕你把所有非 li 节点都 display: none 掉，它们依然参与 nth-child 计数。显隐状态和 DOM 位置是两回事。
立即学习“前端免费学习笔记（深入）”；
