常见原因是tr不是table的直接子元素，如存在thead或tbody导致nth-child计数错位；应改用tbody tr:nth-child(odd)并检查DOM结构确认直系关系。
table tr:nth-child(odd) 为什么没生效？
常见原因是 tr 不是 table 的直接子元素——比如你写了 <tbody> 或 <code><thead>，而 <code>nth-child 是按父元素下的所有子元素顺序计数的。此时 tr 可能被 thead 里的 tr 占掉第1个位置，导致后续奇偶错位。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 用
tbody tr:nth-child(odd)明确限定作用范围，避免受thead干扰 - 检查 DOM 结构：打开浏览器开发者工具，确认
tr确实是目标父容器的直系子节点 - 若需兼容老版本 IE（nth-child 不可用，得用 JS 动态加 class 或服务端渲染 class
用 CSS 自定义属性（颜色变量）控制隔行色
把颜色抽成变量，方便统一维护和主题切换。但注意：变量必须在使用前定义，且作用域要覆盖到 tr。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 在
:root或table上定义：:root { --row-odd-bg: #f9f9f9; --row-even-bg: #ffffff; } - 应用时直接引用：
tbody tr:nth-child(odd) { background-color: var(--row-odd-bg); } tbody tr:nth-child(even) { background-color: var(--row-even-bg); } - 别在
tr上用style="--row-odd-bg: ..."覆盖，因为nth-child是静态选择器，无法按条件切换变量值
nth-child(2n) 和 nth-child(odd) 效果一样吗？
视觉上通常一样，但底层逻辑不同：前者匹配“2 的倍数”（2、4、6…），后者匹配“奇数位置”（1、3、5…）。如果第一行是表头（thead tr），而你对整个 table tr 写 nth-child(odd)，那表头也会被算作第1个，从而染上背景色——这往往不是你想要的。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 明确目标区域：只对
tbody tr使用伪类，而非table tr - 用
nth-child(2n+1)替代odd更直观，也便于后期改成2n+2等偏移模式 - 测试时手动删掉
thead，看样式是否按预期变化，能快速定位是否被头部干扰
表格有合并单元格（rowspan/colspan）还适用 nth-child 吗？
适用，但要注意：伪类只看 DOM 中的元素顺序和层级，跟视觉上的“行”无关。即使某 tr 里有个 td rowspan="3"，它仍只算作当前 tr 的一个子元素，不影响其他 tr 的序号计算。
真正的问题在于视觉错觉：当大 rowspan 打乱了视觉节奏，隔行色可能看起来“断掉”或“重复”。这不是 CSS 失效，而是人眼预期和 DOM 结构不一致。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 保持
tbody内tr数量真实反映数据行数，避免用tr+rowspan模拟空行 - 如必须合并，可配合
tr[data-group="1"]这类语义化属性，用 JS 或服务端打标后针对性着色 - 不要指望
nth-child能感知渲染后的视觉行高或合并状态
最易被忽略的一点：CSS 变量在 @media 或 @supports 中重定义时，若未覆盖全部相关变量，可能导致部分 tr 背景色回退到初始值（比如 transparent），而不是报错或忽略——这种静默失效很难一眼发现。
