Collection接口不能强转为List或Set，因二者是其同级子接口、无继承关系；应通过构造函数如new ArrayList(collection)安全转换。
Collection 接口本身不能强转成 List 或 Set，因为它们是平级接口，没有继承关系。直接写 (List) collection 或 (Set) collection 会抛出 ClassCastException——不是类型“不对”，而是“根本不可能对”。防御的核心不是“怎么转成功”，而是“避免误以为能转”和“用正确方式获取目标类型实例”。
认清接口层级，杜绝非法强转
Java 集合体系中，Collection 是顶层接口，List 和 Set 都是它的**同级子接口**，互不兼容。JVM 要求强转目标必须是对象运行时类型的父类或实现接口，而一个 ArrayList 实例虽同时是 Collection 和 List，但它**不是 Set 的实现类**，所以 (Set) new ArrayList() 必然失败。
- 别写
(List) someCollection—— 即使someCollection实际是ArrayList，编译器也无法保证，运行时可能它是HashSet - 别依赖 IDE 提示或“我刚 new 的肯定是 List”——外部传入的
Collection类型完全不可控 - 检查运行时类型可用
collection.getClass().getName()，但仅用于诊断，不能用于条件强转
用构造函数安全创建目标集合
真正需要 List 或 Set 时，应通过构造函数复制元素，而不是转型。这是语义清晰、类型安全、零异常的标准做法。
-
转成 List：用
new ArrayList(collection)或new LinkedList(collection) -
转成 Set：用
new HashSet(collection)或new LinkedHashSet(collection) - 若需保留插入顺序且去重，优先选
LinkedHashSet；若需排序，用TreeSet（注意元素需可比较） - 这些构造函数接收
Collection extends E>，天然适配任意Collection子类，无需任何强转
从源头约束类型，减少 Collection 泛化使用
很多 ClassCastException 隐患源于方法签名过度宽泛地使用 Collection，导致调用方传入任意实现，下游被迫“猜类型”。
立即学习“Java免费学习笔记（深入）”；
- 如果业务逻辑明确只需要列表（支持索引、重复），方法参数直接声明为
List<T>，而非Collection<T> - 如果只关心唯一性与快速查找，参数用
Set<T>更准确，也便于调用方自觉传入HashSet等 - 对外提供 API 时，返回类型尽量具体：返回
ArrayList比返回Collection更利于使用者预期行为 - 若必须接受
Collection，文档中明确说明“仅支持 List 实现”或“要求无序唯一”，并配合运行时校验（如if (!(collection instanceof List)) throw new IllegalArgumentException(...)）
工具方法封装 + 运行时校验兜底
当确实需要区分处理不同集合类型（比如对 List 做索引访问、对 Set 做 contains 查询），应显式判断实现类型，而非强转。
- 用
collection instanceof List判断是否可作列表处理，再安全调用get(0)等方法 - 用
collection instanceof Set判断是否适合做去重操作，避免在ArrayList上反复调用contains导致性能问题 - 封装工具类方法，例如：
public static <T> List<T> toList(Collection<T> c) { return new ArrayList<>(c); }
public static <T> Set<T> toSet(Collection<T> c) { return new LinkedHashSet<>(c); } - 这些方法内部不涉及任何强转，只做复制，彻底规避
ClassCastException
