nth-of-type 与视觉换行无关，只按DOM中同类型元素的兄弟顺序计数；中间插入注释、文本节点等会导致序号错位，调试时需检查实际兄弟节点构成。
nth-of-type 选不到跨行元素？它根本不看“行”
nth-of-type 只按 DOM 树中同类型元素的顺序计数，和视觉上是否换行、是否被 float 或 flex 拆到下一行完全无关。它不感知布局，只认标签名和兄弟顺序。
常见错误现象：div:nth-of-type(2n) 在 flex 容器里想隔行变色，结果颜色跳着走，甚至漏掉某些 div —— 因为中间插了 p、span 或注释节点，nth-of-type 会跳过它们继续数，导致序号错位。
- 使用场景：适合结构稳定、同类型兄弟元素连续排列的列表（如纯
li列表、纯tr表格行） - 参数差异：
nth-of-type(2)是第 2 个该类型元素；nth-of-type(2n)是所有偶数位置；nth-of-type(3n+1)是第 1、4、7…个 - 性能影响：几乎无运行时开销，但过度嵌套或配合复杂选择器可能触发重排重绘
想控制“视觉上的第 n 行”？CSS 本身做不到
浏览器没有 :nth-row() 或 :nth-visual-line() 这类伪类。所谓“跨行选择”，本质是布局结果，而 CSS 选择器无法读取渲染后的几何信息。
如果你看到某段代码“实现了隔行高亮”，大概率是：
立即学习“前端免费学习笔记（深入）”；
- 用 JavaScript 动态计算每个元素的
getBoundingClientRect()的top值，再分组打 class - 用
grid配合grid-row手动控制，把“行”变成显式轨道，再用:nth-child选轨道内的首项 - 放弃“自动跨行”，改用
display: contents拆解容器，让子元素成为同一级兄弟（慎用，可访问性风险）
flex / grid 容器里更可靠的替代方案
在 flex-wrap: wrap 或 grid 中，真正可控的是“每行固定数量”。这时应优先用容器级控制，而非硬套 nth-of-type。
- Grid 场景：设
grid-template-columns: repeat(3, 1fr)，然后用div:nth-child(3n)选每行最后一个，比nth-of-type更稳 - Flex 场景：加一层 wrapper，每 3 个
div包进一个section，再对section > div:first-child下样式 - 兼容性注意：
display: contents在旧版 Safari 和部分安卓 WebView 中不支持，grid在 IE 中完全不可用
容易被忽略的 DOM 细节：注释、空格、文本节点
nth-of-type 虽然只看元素类型，但它的“兄弟”范围包含所有节点。如果 HTML 里有注释 <!-- comment --> 或换行缩进产生的空白文本节点，它们会占据位置，影响后续元素的索引值。
示例：
<div>A</div> <!-- note --> <div>B</div>
此时 div:nth-of-type(2) 能匹配到 B，但 div:nth-child(2) 就匹配不到 —— 因为第 2 个子节点是注释，不是元素。
- 调试建议：用浏览器开发者工具的“Elements”面板右键 → “Break on > Attribute modifications”，观察实际兄弟节点构成
- 修复方式：删掉模板中的无意义注释/空行，或改用
data-属性代替注释逻辑 - 服务端渲染时尤其要注意：模板引擎（如 EJS、Jinja）默认保留空白，可能意外插入文本节点
DOM 结构越“干净”，nth-of-type 越可靠；一旦混入非元素节点，序号就容易偏移，而且这种偏移很难一眼看出来。
