结论：nth-child(odd/even)仅按DOM顺序选元素，不识别flex/grid的视觉换行，故在响应式布局中失效；真自适应需JS动态计算元素视觉位置并打标。
直接说结论：用 li:nth-child(odd) 和 li:nth-child(even) 就行，但必须确认父容器下只有 li，否则会错位；真要自适应（比如响应式断行、flex-wrap 后视觉“换行”），纯 CSS 无解，得切回 JS。
为什么 nth-child 在 flex 或 grid 列表里经常失效
它数的是 DOM 顺序，不是视觉行。比如你用 display: flex; flex-wrap: wrap; 排 12 个 li，每行 4 个，视觉上第 1 行是 1–4，第 2 行是 5–8……但 nth-child(odd) 仍按 1、3、5、7…选，结果是第 1 行的 1 和 3 变色，第 2 行的 5 和 7 变色——完全不是“隔行”，而是“隔项”。
- 浏览器不感知“视觉换行”，
nth-child只认 HTML 源码顺序 - 哪怕加了
break-inside: avoid;或page-break-inside: avoid;，对 flex/grid 的换行也无效 - grid 中用
grid-auto-rows或grid-template-rows也不能让nth-child按“行”重算索引
nth-of-type 能不能救场
不能。它只过滤同类型子元素，但依然按父元素内全部 li 的顺序编号，和 nth-child 在纯 ul>li 结构里行为一致。如果中间插了 div 或注释节点，两者都会跳过——但都解决不了“视觉换行后重置计数”的问题。
-
ul li:nth-of-type(odd)和ul li:nth-child(odd)在干净结构里效果相同 - 一旦有非
li兄弟（如），两者都可能漏掉或错位，但错的方式不同 - 它不理解“第几视觉行”，所以不是自适应方案
真正能自适应的方案只有 JS 动态打标
监听容器尺寸变化，遍历所有 li，用 getBoundingClientRect() 拿每个元素的 top 值，相同 top（或误差
- 简单实现可只在
resize和数据加载后运行一次，不用ResizeObserver实时监听 - 避免用
offsetTop，它受position: relative等影响，getBoundingClientRect().top更可靠 - 加类名比内联
style更利于维护，例如li.classList.toggle('stripe-row-even', rowIsEven)
退而求其次：用 CSS 自定义属性 + JS 控制变量
如果不想操作 DOM 类名，可以用 JS 设置 style.setProperty('--stripe-row', rowIndex)，再在 CSS 里写：li:nth-child(n) { background: calc(var(--stripe-row) % 2 == 0 ? #f5f5f5 : #fff); }——但注意，CSS 不支持 calc 里用逻辑运算，这行伪代码实际不可用，最终还得靠类名或内联样式。
- CSS 本身没有“当前行号”变量，
--stripe-row必须由 JS 每次重新赋值 - 别试图用
@property做动态计算，目前不支持运行时条件判断 - 最简路径仍是：JS 算好哪几项属于第 N 行 → 给它们加
data-stripe="even"→ CSS 写li[data-stripe="even"]
真正麻烦的从来不是“怎么写 nth-child”，而是当布局脱离线性流之后，你得亲手告诉浏览器“哪几个是一行”。这个活，CSS 还没学会。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
