java泛型擦除统一使用object，因其是所有引用类型的公共直接父类且无额外语义约束；有上界时取最左具体类或接口，无界时默认为object，确保字节码兼容与类型安全。

Java泛型在编译期被擦除，无界泛型（如 T、List<t></t>）统一替换为 Object，这不是随意选择，而是由类型系统约束和字节码兼容性共同决定的。

为什么不是其他类型，比如 Serializable 或 Cloneable？

因为只有 Object 是所有引用类型的公共直接父类，且不引入额外语义约束。若选 Serializable，就会错误地要求所有实参类型都必须可序列化；同理，Cloneable 会强加克隆能力。而 Object 是最宽泛、最安全的上界——它不施加任何运行时行为要求，仅提供基础方法（toString()、equals() 等），符合“最小假设”原则。

编译器如何推导擦除后的边界？

擦除过程遵循“最左、最具体、无歧义”的上界选取规则：

• 若泛型有显式上界（如 <t extends number comparable>></t>），擦除后取第一个接口（Number），因为它是类类型，优先于接口；若全是接口，则取最左那个（Comparable）。
• 若泛型无任何上界（即 <t></t>），等价于 <t extends object></t>，这是语言规范隐含的默认上界，因此擦除为 Object。
• 数组类型、原始类型、通配符（如 ?>）也按同样逻辑归一化：无界通配符 ? 擦除为 Object，与 T 一致。

字节码层面的强制约束

Java 虚拟机不支持泛型，所有泛型信息必须映射到已有指令集。方法签名、字段描述符、类型检查指令（如 checkcast）只接受具体类或接口类型。用 Object 作为占位符，能保证：

• 生成的字节码可被所有 JVM 版本加载执行；
• 类型转换（如 (String) list.get(0)）在运行时通过 checkcast 完成，而该指令的目标类型必须是已加载的类，Object 总是可用；
• 避免因擦除目标不唯一导致的签名冲突（例如两个不同泛型方法擦除后签名相同但语义不同）。

例外情况：基本类型泛型参数不存在

Java 不允许用基本类型实例化泛型（如 List<int></int> 不合法），所以擦除永远不涉及 int、boolean 等。所有泛型参数都对应引用类型，其擦除目标天然落在引用类型体系内，Object 是该体系的根节点。

这个设计不是权衡取舍的结果，而是类型擦除机制能在保持向后兼容前提下唯一可行的实现路径。