:nth-child(odd)和:nth-child(even)最简洁可靠，但要求目标元素是父容器下连续同级子项；其按DOM物理位置（含注释、文本节点等）计数，非视觉行序或同类元素序，故混入其他节点时会错位，此时应改用:nth-of-type(odd)。
直接说结论：用 :nth-child(odd) 和 :nth-child(even) 实现隔行变色最简洁可靠，但必须确保目标元素是**同级兄弟元素中的连续子项**，否则奇偶计算会出错。
为什么 :nth-child(odd) 有时不按“视觉上的第1、3、5行”变色？
因为 :nth-child() 是按 DOM 中的**物理位置索引**（即父容器下第几个子节点），不是按 CSS 渲染后的“可见行”或“同类元素序号”。如果父元素里混有其他标签（比如 <div>、<code><p></p>、注释、空文本节点），它们全算进计数。
- 常见错误场景：表格里
<tr> 前有 <code><caption></caption>或<thead>；列表中 <code><li>之间插了<div class="divider"> <li>验证方法：打开浏览器开发者工具，选中目标元素，看右侧面板里它的 “Child index” 是多少（Chrome DevTools 的 Elements 面板里会显示）</li> <li>替代方案：若需按“第1个 <code><li>、第2个<li>”计数，改用:nth-of-type(odd)—— 它只统计同类型标签（如只算<li>） - 基础写法：
tr:nth-child(odd) { background: #f5f5f5; } tr:nth-child(even) { background: #ffffff; } - 注意：不能简写为
:nth-child(1,3,5...)或:nth-child(2n+1)虽然等价，但odd/even更直观、少出错 - 性能无差异：浏览器内部都转为相同解析逻辑，不用刻意优化写法
- 典型陷阱：二级菜单的
<li>会被一级菜单的父<ul></ul>计入 —— 导致样式错位 - 解决方式：加更精确的选择器前缀，例如
ul.main-menu > li:nth-child(odd)，用>限定直系子元素 - 动态渲染后失效？不是选择器问题，而是新插入的元素没被 CSS 规则覆盖 —— 检查是否漏写了针对新增节点的规则，或是否用了
!important干扰层叠
:nth-child(odd) 和 :nth-child(even) 的写法与兼容性
两者语法完全对称，可单独使用，也可成对声明。现代浏览器（Chrome 4+、Firefox 3.5+、Safari 3.2+、Edge 12+）均原生支持，IE9+ 支持，IE8 及以下不支持（需 JS 回退）。
遇到嵌套结构或动态内容时怎么避免失效？
当列表由 JS 动态插入、或存在多层嵌套（如 <ul><li><ul><li></ul></li></ul>），:nth-child() 仍只作用于**直接父元素下的子节点**，不会跨层级继承或重置计数。
立即学习“前端免费学习笔记（深入）”；
真正容易被忽略的是：哪怕 HTML 结构“看起来很干净”，只要用了自定义元素、Web Components、或者 SSR 渲染时注入了不可见节点（比如服务端生成的空文本节点），:nth-child() 就可能偏移。动手前先 inspect 元素的真实 child index，比猜更省时间。
