Collections.disjoint 判定交集的核心是“快且稳”，采用短路逻辑遍历小集合、调用大集合的 contains，性能取决于集合类型与大小顺序：优先让 HashSet/TreeSet 做被查方，手动控制参数顺序，严防 null、空集合及自定义对象未重写 equals/hashCode。
直接用 Collections.disjoint 判定两个大集合是否有交集，核心不是“有没有”，而是“怎么让它快且稳”。它不构造中间集合，而是走短路逻辑：遍历小集合，对每个元素调用大集合的 contains，一命中就立刻返回 false（即存在交集）。所以关键在集合类型、大小顺序和防御准备。
选对集合类型，性能差十倍不止
底层 contains 的时间复杂度决定整体效率：
-
HashSet / LinkedHashSet / TreeSet：
contains平均 O(1) 或 O(log n)，适合做被查方（即“大集合”角色） -
ArrayList / LinkedList：
contains是 O(n)，若把它当被查方，每次检查都要扫一遍，总耗时可能达 O(小集合大小 × 大集合大小) - 若两个都是
ArrayList，且一个含 10 万元素、另一个含 100 元素，务必把 100 元素的传第一个参数——Collections.disjoint(smallList, bigList)比反过来快近百倍
手动控制遍历与被查角色更可靠
Collections.disjoint 内部有启发式逻辑（比如优先让 Set 做被查方），但不透明。实战中建议显式掌控：
- 如果已知
setB是HashSet，而listA是ArrayList，就写Collections.disjoint(listA, setB)，确保用listA遍历、setB响应contains - 如果两个都是
ArrayList且大小悬殊，别依赖自动判断，自己比较size()后交换顺序传参 - 避免在高频循环里反复调用它比对同一组数据；可提前将被查集合转为
HashSet，再手写一层 for + contains 短路逻辑，更易调试和优化
边界必须防：null、空、自定义对象
三个常见崩点，缺一不可检查：
-
null 引用：任一参数为
null直接抛NullPointerException，调用前必须判空：if (a == null || b == null) throw new IllegalArgumentException(...) -
空集合：任一为空，结果恒为
true（无交集），这是合法行为，但需确认业务是否允许空集合参与判定 -
自定义对象：若集合装的是自定义类（如
User），必须正确重写equals和hashCode；否则即使字段值相同，contains也识别不出，导致误判为“无交集”
替代方案只在特定场景值得考虑
不要为了“看起来更底层”而自己重写 disjoint 逻辑，除非满足以下全部条件：
- 你已确认
Collections.disjoint成为性能瓶颈（例如 JFR 或 profiler 显示它占 CPU 高峰 30%+） - 被查集合无法转成
HashSet（比如内存受限或元素不可哈希） - 你需要额外语义，比如记录第一个交集元素、或跳过某些过滤条件
- 否则，它已经足够简洁、安全、经过 JDK 长期验证
