:nth-child(odd)没生效主因是<thead>等干扰计数，应限定为tbody tr:nth-child(odd)；:nth-child(even)与2n等价；IE8不支持，需JS降级；rowspan不影响序号但可能遮挡背景色。
为什么 :nth-child(odd) 有时没生效？
直接写 tr:nth-child(odd) { background: #f5f5f5; } 却发现第一行没变色，大概率是因为 <thead> 或 <caption> 干扰了计数。浏览器按 DOM 树中实际子元素顺序编号，<thead> 里的 tr 也算在内 —— 所以如果表头占 1 行，真正的数据行 tr 就从第 2 个子元素开始，odd 匹配到的是第 3、5、7… 行，视觉上就“跳过了第一行”。
解决办法是只对 <tbody> 内的 tr 应用规则：
tbody tr:nth-child(odd) { background: #f9f9f9; }
tbody tr:nth-child(even) { background: #fff; }
- 确保 HTML 中显式写出
<tbody>（即使浏览器会自动补全，显式写更可控） - 避免把
tr直接写在table下（不规范，且破坏:nth-child的预期行为） - 若用 JS 动态插入行，注意新
tr是否被正确 append 到tbody
:nth-child(2n) 和 :nth-child(even) 有区别吗？
没有实质区别 —— 浏览器把 even 当作 2n 的别名解析，两者完全等价。同理 odd 等价于 2n+1。但要注意：:nth-child(2n+1) 和 :nth-child(odd) 都是从第一个子元素开始算起，不是从当前选择器匹配的元素开始。
常见误用场景：
立即学习“前端免费学习笔记（深入）”；
- 写成
tr:nth-child(2n+1)但没限定tbody，结果把<thead> tr也计入，导致样式错位 - 以为
:nth-of-type更合适 —— 其实它按元素类型（如tr）计数，不依赖位置，但表格里tr类型唯一，效果和:nth-child一致；真要跨区域统一编号（比如忽略thead），还是得靠结构限定
兼容性与性能：IE8 能用吗？
:nth-child() 在 IE9+ 和所有现代浏览器中都支持，IE8 及更早版本**完全不支持**。如果你必须兼容 IE8，不能依赖 CSS 伪类，得用 JS 或服务端逻辑给奇偶行加 class（如 class="odd" / class="even"），再写对应规则。
性能方面无需担心：:nth-child 是 CSS 引擎原生支持的伪类，渲染时一次性计算，比 JS 遍历 tr 并 setAttribute 快得多，也更轻量。
- 别为了“兼容旧版”在现代项目里加冗余 JS 逻辑
- 若用 CSS-in-JS（如 styled-components），确保生成的 class 名不意外覆盖
tbody tr的层级关系
遇到合并单元格（rowspan）怎么办？
:nth-child 只看 HTML 结构中的位置，不管视觉是否被 rowspan 拉伸。比如某行有 rowspan="2"，它仍只算一个 tr 元素，后续行的序号照常递进 —— 所以隔行色不会因合并单元格而错乱。
真正的问题在于视觉观感：被拉伸的行背景色会覆盖下方行的部分区域，可能让下一行的背景“看不见”。这不是选择器失效，而是层叠顺序问题。
- 可对带
rowspan的tr单独设置background，或用z-index+position: relative微调（但慎用，表格元素对position支持有限） - 更稳妥的做法是避免在需要严格隔行色的表格中滥用
rowspan，或改用border-collapse: separate+border-spacing控制间距，减少视觉干扰
最易被忽略的一点：当表格内容动态加载或排序后，:nth-child 会自动重算 —— 这是优势，但如果你同时用了 JS 手动加 class 控制高亮，两种机制可能冲突，记得清理旧 class 或统一用 CSS 方案。
