java集合框架核心是解决数组长度固定、类型不安全、操作冗余三大硬伤；它通过接口抽象数据关系（collection为“一堆东西”，map为“映射规则”），泛型保障编译期类型安全，但实现类切换可能引发隐性性能退化。
Java集合框架的核心作用，是替代数组完成动态、安全、可组合的数据管理。它不是“增强版数组”，而是为解决数组在真实开发中必然暴露出的三大硬伤而生：长度固定、类型裸奔、操作裸写。
为什么不能继续用 new String[100]？
这不是风格问题，而是运行时风险。一旦插入第101个元素，ArrayIndexOutOfBoundsException直接中断流程；想删掉所有空字符串？得手写循环+条件判断+数组复制——这些本不该由业务代码承担。
- 数组扩容必须手动：
String[] newArr = Arrays.copyOf(oldArr, oldArr.length * 2)，而ArrayList.add()把这层逻辑完全封装 - 数组不提供语义化操作：
contains()、retainAll()、sort()全要自己实现，且无法复用 - 多维或键值场景极其别扭：
Map<string list>></string>比Order[][]更贴近“用户→订单列表”这个业务概念
Collection 和 Map 为什么是两套平行接口？
因为它们抽象的是两类根本不同的数据关系：一个是“一堆东西”，一个是“映射规则”。强行让 Map 继承 Collection，就像让“字典”继承“购物篮”——put("apple", 5.9) 和 add("apple") 的语义完全不兼容。
-
Collection方法如add(E)、remove(Object)都围绕单值设计 -
Map的核心是put(K,V)、get(K)，它的keySet()返回的是Set视图，不是继承关系 - 误以为
HashMap是Collection会导致编译失败（比如调用add()）或逻辑错乱（比如把size()当成“值个数”而非“键值对个数”）
泛型擦除后还安全吗？
安全，但只在编译期生效。擦除不是“没用”，而是把类型检查前移到写代码阶段。
立即学习“Java免费学习笔记（深入）”；
-
List<string> list = new ArrayList(); list.add(123);</string>→ 编译直接报错：error: incompatible types: Integer cannot be converted to String - 不会生成可能触发
ClassCastException的字节码，也就杜绝了运行时因类型错误导致的崩溃 - 但注意：反射绕过泛型检查、原始类型混用（如
ArrayList赋值给List<string></string>）仍可能引入隐患
真正容易被忽略的，是接口与实现分离带来的隐性成本：你声明 List<string> names = new ArrayList();</string> 很自然，但如果某天换成 LinkedList，names.get(5000) 就会从 O(1) 变成 O(n)——语义没变，性能却断崖下跌。选实现类，从来不只是“能用就行”。
