:not(:first-child)失效是因为它依赖第一个子元素恰好是目标类型；若父容器开头有其他元素或文本节点，所有目标元素均不匹配:first-child，导致全部被选中。
直接用 :not(:first-child) 最省事，但得看结构是否“干净”——如果父容器里混着其他类型元素（比如 div 里夹着 p 或注释节点），:first-child 可能根本没选中你预期的那个元素。
为什么 :not(:first-child) 有时失效
它依赖“第一个子元素恰好是你想排除的那个”。比如父元素是 <ul></ul>，里面全是 <li>，那 li:not(:first-child) 没问题；但如果 <ul></ul> 开头有个 <span class="label"></span>，那第一个子元素就是这个 span，所有 li 都不是 :first-child，结果全部被选中——完全违背本意。
- 检查 DOM 结构：用浏览器开发者工具看父元素的子节点顺序，确认第一个子节点是否真是目标元素类型
- 避免依赖
:first-child做类型判断，它只认位置，不认标签名 - 若父元素结构不可控（如 CMS 输出、用户编辑内容），优先考虑
:nth-of-type或兄弟选择符
:nth-child(n+2) 和 :nth-of-type(n+2) 的区别
前者按“所有子元素位置”计数，后者只按“同类型元素位置”计数。例如父元素内有 <h2></h2>、<p></p>、<p></p>、<div>：
<ul>
<li>
<code>p:nth-child(n+2) → 选中第二个 p（它是第3个子元素），但跳过第一个 p（它是第2个子元素，满足 n+2 当 n=0）→ 实际选中第2、3个 p？不对，它只匹配位置为 2、3、4… 的子元素，而第一个 p 在位置2，所以会被选中；第二个 p 在位置3，也被选中；div 在位置4，但不是 p，不匹配
p:nth-of-type(n+2) → 只看 p 类型的序号：第一个 p 是 type-1，第二个是 type-2，所以从 type-2 开始匹配 → 精准排除第一个 p
结论：要排除“第一个同类型元素”，用 :nth-of-type(n+2) 更可靠；要排除“物理位置上的第一个子元素（不管类型）”，才用 :nth-child(n+2)。
用兄弟选择符 + 和 ~ 的实操边界
它们不依赖伪类计算，纯靠 DOM 关系，性能好、兼容性高（IE7+），但要求目标元素和前一个元素是同级且相邻（或后续）。
-
.item + .item→ 只匹配紧接在另一个.item后面的.item，即从第二个开始，但不包括第三个以后“非紧邻”的（其实会，因为每个.item只要前面有同级.item就命中） -
.item ~ .item→ 匹配所有在某个.item后面的同级.item，等价于“除第一个外的所有”——只要它们是连续同级兄弟 - 注意：如果中间插了其他元素（如
<hr>或文本节点），~仍有效，+会断掉 - 不能用于嵌套结构，比如想选
.list > div中除第一个外的，必须确保这些div确实是同级兄弟
动态插入内容时最容易忽略的点
JS 动态添加元素后，:first-child 和 :nth-child 会实时重算，但 :first-of-type 和兄弟选择符行为一致——问题不在选择器本身，而在你是否假设了初始 DOM 结构不会变。
- 服务端渲染 + 客户端 hydrate 场景下，首屏 HTML 里第一个元素可能是占位符，JS 加载后替换成真实内容，此时
:first-child可能指向旧节点 - 使用
innerHTML批量替换子元素时，整个子树重建，所有索引重排，nth-child行为符合预期，但视觉上可能闪动 - 真正难搞的是 fragment 插入或
append()单个节点——这时~和+依然生效，但:nth-of-type(n+2)要求插入的节点类型和原有结构一致
实际项目里，如果父容器结构简单且稳定，:nth-of-type(n+2) 是最省心的选择；一旦涉及混合类型、动态插入或 SSR/CSR 差异，就得拉出开发者工具逐层 inspect 子节点构成，而不是凭直觉写选择器。
