为何Apache CollectionUtils的containsAny方法无需相同泛型类型的集合？

• 历史兼容性考量：Apache Commons Collections早在Java泛型（JDK 1.5引入）诞生前就已存在，早期版本没有泛型约束。后续添加泛型支持时，为了兼容大量已有的非泛型代码，不能设置过于严格的泛型匹配要求——如果强制要求两个集合泛型完全一致，旧代码会直接编译失败，这显然不符合工具库的向后兼容原则。

• 业务场景的灵活性需求：实际开发中确实存在泛型不同但需要判断元素交集的场景。比如两个集合的元素类型虽不同，但重写了equals方法实现语义上的相等判断（例如User实体类和UserDTO数据传输对象，按用户ID判断相等）；或是父类与子类集合（如List<Number>和List<Integer>），这类场景下containsAny的泛型宽松设计能直接满足需求，无需额外类型转换。

• Java泛型擦除的本质限制：Java泛型仅在编译期生效，运行时会被擦除。即便containsAny设置严格泛型约束，开发者依然可以通过反射、非泛型集合强制转换等方式绕过。所以严格的泛型更多是编译期的语法提示，Commons Collections的设计选择把逻辑判断的自主权交给开发者，而非强制约束。

• 通用工具类的设计哲学：作为通用工具库，Commons Collections的目标是覆盖尽可能多的使用场景，而非仅满足“同类型集合检查”这单一需求。宽松的泛型设计能让工具适配更多业务场景，给予开发者更大的选择权。

如果你更倾向于严格的同类型集合检查，可以自行封装一层方法，在编译期强制约束泛型一致：

public static <T> boolean containsAnyStrict(Collection<T> coll1, Collection<T> coll2) {
    return org.apache.commons.collections4.CollectionUtils.containsAny(coll1, coll2);
}

内容的提问来源于stack exchange，提问作者Davide C