结论是：tr:nth-child(even/odd)需显式包裹tbody且结构干净才可靠；tbody tr:nth-of-type(even/odd)更鲁棒，因只计tr类型、无视thead等干扰；li等列表优先用nth-of-type避免注释或div导致序号偏移。
直接说结论：用 tr:nth-child(even) 和 tr:nth-child(odd) 能快速实现表格条纹，但前提是 HTML 结构干净、tr 全在 tbody 里；列表用 li:nth-of-type(odd) 更稳，因为 :nth-child 容易被注释、div 或换行符“卡住”。
为什么 tr:nth-child(even) 有时不生效？
浏览器会自动插入 tbody，哪怕你没写。所以你写的 tr:nth-child(even) 实际匹配的是 table 的子元素——而 thead 里的 tr 和自动包裹的 tbody 里的 tr 是不同层级的子元素，计数被拆开，条纹就断了。
常见错误现象：tr:nth-child(even) 只给第一组 tr 上色，后面全没反应；或者表头也被染上背景。
- 显式写出
<tbody> 标签，把所有数据行包进去 <li>改用 <code>tbody tr:nth-child(even)，限定作用域 - 如果用了
thead，确保它和tbody是同级兄弟，别被额外div包裹 - 优先用
li:nth-of-type(odd)，它无视其他兄弟节点，只按li自身顺序编号 - 不要写
li:nth-child(2n)，语义不如even直观，还容易手误 - IE8 不支持这两个伪类，如需兼容，得靠 JS 或服务端打
class="odd"/class="even" - 纯 CSS 无法实现“视觉意义上的隔行条纹”，
:nth-child和:nth-of-type都做不到 - 真要响应式隔行（比如移动端单列、桌面端三列时都保持每视觉行交替），必须用 JS 动态计算元素位置并加 class
- 如果只是固定列数，可用
li:nth-child(6n+1), li:nth-child(6n+3), li:nth-child(6n+5)模拟三列下的奇数行，但维护成本高
li:nth-child(odd) vs li:nth-of-type(odd) 怎么选？
:nth-child() 数的是父元素下所有子节点顺序（包括注释、文本节点、div），:nth-of-type() 只数同类型标签（比如只数 li）。实际项目中，HTML 很难保证“只有 li”。
比如这个结构：<ul>
<li>A</li>
<div class="ad"></div>
<li>B</li>
</ul>，li:nth-child(odd) 会匹配第一个 li（它是第1个子元素），但第二个 li 是第3个子元素，仍算 odd；可一旦中间插个注释节点，序号就全偏移。
flex/grid 布局下 :nth-child 还能当“隔行”用吗？
不能。它永远按 DOM 源码顺序计数，不感知视觉换行。比如 display: flex; flex-wrap: wrap; 排 12 个 li，每行 4 个，li:nth-child(odd) 选的是第 1、3、5、7、9、11 个 li，结果是每行前两个变色，根本不是“隔行”。
这不是 bug，是设计如此——CSS 伪类不负责理解布局流。
真正麻烦的不是写法，而是你没法靠看效果反推 DOM 结构是否“干净”。调试时打开开发者工具，右键检查目标 li 或 tr，往上点到父元素，挨个看子节点列表——有没有注释、空格文本、意外插入的 div，这些才是让 :nth-child 失效的元凶。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
