collection接口定义的核心方法包括add、remove、contains、size、isempty、iterator、toarray、clear，jdk 8+新增removeif、stream、parallelstream；它不提供get或put因遵循职责分离原则，由list、map、set、queue等子接口/体系承担差异化功能。
Java 中的 Collection 接口本身不包含具体实现，它是一组操作单列集合的顶层契约，定义了增删查、批量操作、迭代和比较等通用行为。真正“包含”的是方法签名和语义约定，而非字段或默认逻辑（JDK 8+ 后增加了少量 default 方法）。
Collection 接口定义的核心方法有哪些
这些方法构成所有单列集合（如 ArrayList、HashSet、LinkedList）必须支持的基础能力：
-
add(E e)：添加元素，返回boolean表示是否成功（例如Set会拒绝重复） -
remove(Object o)：按值删除一个匹配元素（注意不是按索引），依赖equals() -
contains(Object o)：判断是否包含某元素，同样基于equals() -
size()和isEmpty()：获取长度与判空 -
iterator()：返回Iterator<e></e>，是 for-each 循环的底层支撑 -
toArray()及其泛型重载toArray(T[] a)：转数组，后者可避免类型擦除问题 -
clear()：清空全部元素 - JDK 8+ 新增：
removeIf(Predicate super E> filter)、stream()、parallelStream()
为什么 Collection 不提供 get(int index) 或 put(K,V) 这类方法
因为接口设计遵循「职责分离」原则：Collection 描述的是「一组元素」的共性操作，不承诺顺序、不承诺键值映射、也不承诺是否允许重复。这些差异由子接口承担：
- 需要按索引访问？→ 交给
List（它扩展了Collection并添加get(int)、set(int, E)等） - 需要键值对？→ 走
Map体系，它根本不是Collection的子接口（Map是独立顶层接口） - 需要去重且无序？→
Set扩展Collection，但明确禁止重复 - 需要队列行为（FIFO/LIFO）？→
Queue及其子接口（如Deque）添加offer()、poll()等
强行在 Collection 中塞入 get(int)，会让 HashSet 这类无索引结构无法合理实现——它连“第 3 个元素”都没定义。
立即学习“Java免费学习笔记（深入）”；
常见误用：把 Collection 当实现类或混淆其与 Iterable 的关系
开发者常犯两类错误：
- 写
Collection list = new ArrayList();—— 语法合法但语义弱，丢失List特有方法（如get()），应优先用具体子接口类型声明 - 以为
Collection继承自Iterable→ 实际上它确实继承了（自 JDK 5），所以能用于 for-each；但反过来，仅实现Iterable的类（如某些自定义数据源）未必是Collection子类，不能直接调用size()或add() - 忽略
Collection方法的异常契约：例如add()在不可变集合（Collections.unmodifiableList()返回值）中会抛UnsupportedOperationException，而非静默失败
public class CollectionBasics {
public static void main(String[] args) {
// 正确：用 List 声明，保留索引能力
List<String> names = new ArrayList<>();
names.add("Alice");
System.out.println(names.get(0)); // ✅
// 危险：用 Collection 声明，后续无法调用 get()
Collection<String> data = new ArrayList<>();
data.add("Bob");
// System.out.println(data.get(0)); // ❌ 编译错误：Collection 没有 get 方法
}
}
真正容易被忽略的是：Collection 的方法行为高度依赖具体实现类的语义。比如 remove(Object) 在 ArrayList 中平均时间复杂度是 O(n)，而在 LinkedList 中也是 O(n)（需遍历找节点），但 HashSet 是 O(1)。不看实现就假设性能，线上容易翻车。
