结论：:nth-of-type 和 :not() 可组合使用，但序号计算与类名过滤分两步独立进行；:nth-of-type(2):not(.disabled) 匹配第2个同类型元素且该元素无.disabled类，而非第2个非.disabled元素。
直接说结论： :nth-of-type 和 :not() 可以组合使用，但必须注意层级与逻辑顺序——:not() 不能直接“否定” :nth-of-type 的序号计算逻辑，它只负责过滤已匹配的元素；真正精准筛选靠的是「先限定类型再排除特征」或「先排除再取序号」的分步思维。
为什么 :nth-of-type(2):not(.disabled) 不一定选中第 2 个非 disabled 元素？
因为 :nth-of-type(2) 先按标签类型（如 li）在父容器中找第 2 个 li，**不管它有没有 .disabled 类**；然后 :not(.disabled) 才检查这个已确定的元素是否满足条件。如果第 2 个 li 恰好是 li.disabled，整个选择器就失效——它不会跳到第 3 个去匹配。
- 错误预期：「第 2 个非 disabled 的
li」 - 实际行为：「第 2 个
li，且它不能有.disabled」 - 这意味着：序号计算与类名判断是两个独立阶段，不可互换顺序
想选「第 n 个符合条件的同类型元素」，该怎么做？
纯 CSS 没有「先过滤再编号」的伪类（类似 JS 的 Array.filter().at(n)），但可通过结构设计绕过限制：
- 把需要排除的元素用不同标签包裹（如把
.disabled改成span或div），让:nth-of-type天然跳过它们——因为它们已不属于同一类型 - 用
:nth-child+:not()替代（前提是目标元素在兄弟中位置可控）：li:not(.disabled):nth-child(2)表示「第 2 个子元素，且是li并非.disabled」，但需确保第 2 个子元素确实是li - 更稳妥的做法：服务端或 JS 预处理，给符合条件的元素加特定类（如
li.active:nth-of-type(2)），把逻辑移出 CSS
:not() 在组合中容易被忽略的兼容性与嵌套限制
:not() 内部只能写简单选择器（不能含空格、不能含伪类链），所以 :not(li.disabled) 合法，但 :not(li .disabled) 或 :not(:hover) 在旧版 Safari（≤15.4）和部分 Android WebView 中不支持。
立即学习“前端免费学习笔记（深入）”；
-
:nth-of-type(3):not([data-status="draft"])✅ 安全（属性选择器） -
:nth-of-type(3):not(.item--hidden:hover)❌ Safari 15.3 及以下会完全忽略整条规则 - 多个
:not()连用时，浏览器仍按从左到右解析，例如li:not(.a):not(.b)等价于「是li，且没有.a，且没有.b」，不是「既不是.a也不是.b的任意元素」
真正难的不是写对语法，而是想清楚「序号是谁算的」「过滤是在哪一步发生的」——CSS 选择器没有执行栈，只有静态匹配流程。一旦结构稍复杂，比如中间穿插注释节点、动态插入元素或使用 display: none，:nth-of-type 的行为就更难预测。这时候，宁可多加一个 class，也别硬套组合伪类。
