:nth-child(odd) 没生效主因是它匹配父元素下所有子元素的序号，而非仅tr元素；混入注释、空格、thead/tfoot或结构不规范都会导致错位，应优先用:nth-of-type(odd)或限定tbody作用域。
为什么 :nth-child(odd) 有时没生效？
直接写 tr:nth-child(odd) { background: #f0f0f0; } 却发现偶数行反而变色，甚至全无反应——大概率是忽略了 DOM 结构中的干扰节点。比如 <tbody> 里混入了注释、空格文本节点，或者表格中存在 <thead>/<tfoot>，这时 :nth-child() 计算的是父元素下的**所有子元素序号**，而非“第几个 tr”。
实操建议：
- 优先用
tr:nth-of-type(odd)：它只计同类型（tr）元素，跳过文本节点和其他标签，更符合直觉 - 确保目标
tr真的在同一个父容器下；若用了<thead>，需分别对thead tr和tbody tr单独写规则 - 检查是否被更高优先级样式覆盖（如内联
style或 ID 选择器），可用浏览器开发者工具的“Computed”面板验证
:nth-child(odd) 和 :nth-child(even) 的边界行为
它们不是“隔行”，而是严格按位置索引匹配：1,3,5... 和 2,4,6...。这意味着如果第一行是 <tr><th>标题</th></tr>，它也会被 :nth-child(odd) 选中并上色——即使你只想给数据行变色。
常见应对方式：
立即学习“前端免费学习笔记（深入）”；
- 给数据行统一加类名（如
class="data-row"），改用.data-row:nth-child(odd) - 用
tbody tr:nth-child(odd)锁定仅作用于<tbody>内的tr，前提是结构规范 - 避免用
:nth-child(2n+1)替代odd——二者等价，但可读性更低，且不解决根本问题
兼容性与性能要注意什么？
:nth-child() 在 IE9+ 完全支持，但 IE8 及更早版本不支持。如果必须兼容 IE8，只能用 JS 动态加类，或服务端渲染 class（如 class="row-odd"）。
性能方面，现代浏览器优化得很好，但若表格超大（>5000 行）且频繁重排，:nth-child 触发的样式计算仍可能轻微拖慢渲染。此时更稳妥的做法是：
- 用 CSS 自定义属性 + JS 控制根级 class（如
:root[data-theme="zebra"] tbody tr:nth-of-type(odd)），便于开关 - 避免嵌套过深的选择器，例如
table tbody tr td:nth-child(odd)不仅难维护，还可能意外匹配到单元格而非行
别把 :nth-child(odd) 当万能隔行方案
它只适用于“连续、同级、结构可控”的场景。遇到动态插入/删除行、展开折叠行、虚拟滚动列表，或使用了 display: contents 的表格，:nth-child 会立刻失效——因为 DOM 序号变了，但视觉顺序没变。
这时候真正该用的不是 CSS 伪类，而是：
- 框架提供的 key-based 渲染（如 React 中根据 index % 2 设置 className）
- 用
background-image: linear-gradient(...)模拟条纹背景（适合固定高度行） - 服务端或构建时预计算 class，规避运行时依赖 DOM 位置
记住：:nth-child(odd) 是个结构匹配工具，不是视觉逻辑工具。一旦结构和视觉脱节，它就不可靠。
