根本原因是v-if移除元素但v-else或空白文本节点仍参与:nth-child全局计数；:nth-of-type仅统计同标签元素，更可靠；推荐用响应式数据驱动序号类替代伪类。
Vue中v-if/v-else导致:nth-child计数偏移
根本原因是 v-if 移除的是整个元素节点，但 v-else 或相邻的静态节点（比如换行、注释、<div class="spacer">）仍保留在 DOM 中，继续参与 <code>:nth-child 的全局计数。浏览器不会因为某元素“不可见”就跳过它——只要它还在父元素子节点列表里，就占一个位置。
常见错误结构：
<ul> <li v-if="showFirst">第一项</li> <li v-else>备用项</li> <li>第二项</li> </ul>
当 showFirst 为 false 时，<li v-else> 渲染，它变成第一个 <li>，但它在父 <ul> 中是第 2 个子节点（前面有换行生成的 #text 节点），所以 li:nth-child(1) 不匹配，li:nth-child(2) 才命中——而你本意只是想选“渲染出来的第一个 <li>”。
- 用 DevTools 右键
<ul>→ “Edit as HTML”，看真实子节点顺序，别信折叠后的 Elements 视图 - 模板中关闭
preserveWhitespace: false（Vue 2）或启用compilerOptions.whitespace: 'condense'（Vue 3），减少文本节点干扰 - 避免在条件分支之间留空行；把
v-if/v-else写在同一行，或用<template>包裹多节点分支
为什么li:nth-of-type(2)比li:nth-child(2)更可靠
:nth-of-type(n) 只统计同标签（这里是 <li>）的兄弟元素，自动忽略 v-if 没渲染的节点、#text、注释、<div> 等杂节点。它不关心 DOM 位置，只关心“这是第几个 <li>”。
立即学习“前端免费学习笔记（深入）”；
例如：
<ul> <!-- banner --> <li v-if="a">A</li> <li v-else>B</li> <li>C</li> </ul>
当 a === false，实际 DOM 是：<!-- banner --> + <li>B</li> + <li>C</li>。li:nth-child(2) 会失败（第 2 个子节点是注释）；li:nth-of-type(2) 则稳定匹配 C——因为它是第二个 <li>。
- 只要你的目标是“第 N 个同类元素”，无脑用
:nth-of-type -
:nth-of-type在 Vue 动态列表、CMS 插入广告、用户富文本等混合场景下容错率高得多 - 注意：IE8 不支持
:nth-of-type，现代项目基本不用考虑
更稳妥的替代方案：用 JS 控制序号类
当样式逻辑必须严格对应“当前可见的第 N 项”（比如斑马纹、首尾特殊边框、折叠面板序号），纯 CSS 伪类已不可靠。Vue 中应改用响应式数据驱动 class。
推荐做法：
- 在
computed或setup()中过滤出可见项：const visibleItems = items.filter(item => item.show) - 给每项加索引：
visibleItems.map((item, index) => ({ ...item, order: index + 1 })) - 模板中绑定：
<li :class="{ 'first': order === 1, 'last': order === visibleItems.length }"> - CSS 写成
.first/.last，彻底绕过伪类计数逻辑
这种写法不依赖 DOM 结构干净度，也不受 v-if、v-show、display: none 影响，且能自然适配搜索过滤、排序等后续交互。
容易被忽略的底层事实
:nth-child 的计数永远只发生在**直接父元素的子节点层**，它不会穿透 <template>、不会识别 Fragment、也不会感知 key 变化。Vue 的 reactivity 和 patch 过程再智能，也无法改变浏览器原生伪类的匹配规则——它只读 DOM 树，不读 Vue 实例。
这意味着：哪怕你用 key 强制重渲染、用 v-memo 优化，只要最终插入的子节点序列里夹着注释或文本，:nth-child 就可能错位。真正可控的，永远是显式暴露的序号状态，而不是隐式推导的位置。
