nth-of-type对tr失效是因为tr的父元素是tbody（或thead/tfoot），而table的直接子元素并非tr；正确写法应限定为tbody tr:nth-of-type(odd)等。
nth-of-type 为什么对 tr 不起作用？
直接写 tr:nth-of-type(odd) 看似合理，但实际常失效——因为 tr 的父元素是 tbody（或 thead/tfoot），而浏览器会自动补全这些包裹标签。如果 HTML 中没显式写出 <tbody>，tr 实际上是 tbody 的子元素，但 nth-of-type 是按**同类型兄弟元素顺序**计数的，而 tbody 下可能混有 tr 和其他节点（比如注释、空格文本节点不影响，但 th 在 thead 里就属于不同父容器）。更关键的是：多个 tr 在同一 tbody 内，nth-of-type 才能正常工作；但如果误把 tr 当作 table 的直接子元素选，就会匹配不到。
正确写法：限定父容器并确保结构清晰
必须明确作用域，且推荐显式写出 <tbody>。否则依赖浏览器自动补全，容易因解析差异导致选择器行为不一致。
- ✅ 正确结构：
<table> <thead><tr><th>Name</th></tr></thead> <tbody> <tr><td>Alice</td></tr> <tr><td>Bob</td></tr> </tbody> </table> - ✅ 对应 CSS：
tbody tr:nth-of-type(odd) { background: #f5f5f5; } tbody tr:nth-of-type(even) { background: #fff; } - ⚠️ 错误写法：
table tr:nth-of-type(odd)—— 因为table的直接子元素是thead/tbody，不是tr，所以永远匹配不到
nth-of-type vs nth-child：选哪个更稳？
nth-of-type 和 nth-child 在纯 tr 序列中效果相同，但稳定性不同：
-
tr:nth-child(odd)按所有兄弟节点位置算（包括非tr），只要tr连续排列，就没问题 -
tr:nth-of-type(odd)只统计同为tr的兄弟，更语义准确，但前提是父容器下没有其他类型元素干扰（比如中间插了个<div>或注释节点不会影响，但<tr class="spacer">仍会被计入） - 如果表格含
<tr class="summary">这类功能性行，又想只给数据行变色，用tbody > tr:not(.summary):nth-of-type(odd)更安全
兼容性与真实场景踩坑点
IE8 不支持 nth-of-type 和 nth-child，如需兼容，得用 JS 或额外 class（如 class="odd"）；现代项目基本可放心用，但要注意：
立即学习“前端免费学习笔记（深入）”；
- 动态插入
tr后，CSS 会自动生效，无需手动重算 —— 但若用innerHTML替换整个tbody，新插入的tr会重新获得序号，没问题 - Vue/React 中用
v-for或.map()渲染tr，只要 key 正确、DOM 结构干净，nth-of-type行为完全一致 - 最易忽略的一点：表格如果有合并单元格（
rowspan），视觉上“奇偶”可能错位，但 CSS 仍按 DOM 顺序着色 —— 这不是 bug，是预期行为；若要视觉对齐，得靠 JS 计算可见行号
