表格奇偶行变色出错主因是未限定作用范围，应使用 tbody tr:nth-child(odd/even) 精准匹配数据行，避开 thead、tfoot 及非数据 tr 干扰，确保按物理位置正确计数。
为什么表格奇偶行变色总出错？先看 DOM 结构是否干净
直接写 tr:nth-child(odd) 很可能把 <thead> 里的 <code><tr> 算进去，导致第一行数据被当成“第2个 <code>tr”，结果偶数色上身。更糟的是，如果表格里插了 <tr class="divider"> 或动态加载的展开行，它们也参与 <code>:nth-child 计数——这不是 bug，是它本来的设计逻辑。
真正起作用的不是“第几行数据”，而是“父容器下第几个 tr 元素”。所以别怪样式不生效，先检查浏览器开发者工具里 tbody 外有没有额外 tr 节点。
tbody tr:nth-child(odd) 是最稳妥的写法
限定在 tbody 内选择，能天然避开 <thead> 和 <code><tfoot> 的干扰，也不受 <code><colgroup></colgroup> 影响。实测下来，这是目前兼容性、可维护性和语义清晰度平衡最好的方案。
-
tbody tr:nth-child(odd)匹配tbody下所有tr中序号为奇数的节点（即第1、3、5…个tr） -
tbody tr:nth-child(even)同理，匹配第2、4、6…个tr - 必须同时定义
odd和even，否则 hover 或其他状态样式可能意外覆盖未声明的一方 - 遇到
rowspan或colspan不影响计数，但视觉错位属于布局问题，不是 CSS 选错了
:nth-of-type(odd) 看似合理，但实际更难控制
:nth-of-type 只统计同标签类型（比如只算 tr），听起来比 :nth-child 更“智能”。但它有个隐藏陷阱：如果 tbody 里混进了 <div>、<code><template></template> 或自定义元素，:nth-of-type 会跳过它们继续计数；而 :nth-child 则完全无视标签类型，只按 DOM 顺序硬排。
这意味着：
- 结构干净时，
tr:nth-of-type(odd)和tbody tr:nth-child(odd)效果一致 - 一旦插入非
tr元素（比如服务端渲染加的占位<tr class="loading">），<code>:nth-of-type会把第1个真实数据tr当作“第1个tr”，而:nth-child可能把它当第3个——结果谁对谁错，取决于你想要的“逻辑行号”还是“物理位置” - IE9+ 全支持
:nth-child，:nth-of-type也是，但行为差异会让团队协作时更难对齐预期 - 把
tr:hover放在奇偶规则下方，并加!important - 或者改用
tbody tr:hover提升特异性，避免依赖加载顺序 - 若用 CSS-in-JS 或模块化方案，注意局部作用域可能让选择器失效，得显式穿透（如
:global(tr:hover)）
hover 覆盖奇偶色时，别忘了 !important
鼠标悬停高亮常用 tr:hover { background-color: #d0e7ff; }，但如果不加 !important，它大概率会被 odd/even 规则覆盖——因为两者权重相同，后写的才生效。而你无法保证 hover 样式一定在奇偶规则之后加载。
更可靠的做法是：
真正容易被忽略的不是语法，而是“谁在数行”——:nth-child 数的是 DOM 位置，:nth-of-type 数的是标签类型，而人脑默认想数的是“第几条数据”。三者不一致时，问题就藏在 HTML 结构里，不在 CSS 行数上。
