java需要桥接方法的根本原因是类型擦除破坏多态一致性：泛型编译后类型参数被擦除为object或上界，导致子类set(string)无法覆盖父类擦除后的set(object)，jvm因签名不匹配而找不到重写方法，故编译器插入桥接方法以维持多态语义。
Java需要桥接方法的根本原因：类型擦除破坏了多态一致性
Java泛型在编译后会把所有类型参数（如 T）擦除为 Object 或其上界，导致父类和子类的方法签名在字节码层面不匹配。比如：
-
泛型父类
Box<t></t>的set(T)擦除为set(Object) -
具体子类
StringBox extends Box<string></string>显式重写的是set(String) - 但 JVM 调用时只认方法签名——
set(Object)和set(String)是两个不同方法，子类并未真正覆盖父类方法
没有桥接方法，多态调用就会失败：通过 Box<string> ref = new StringBox()</string> 调用 ref.set("ok")，JVM 找不到可继承的 set(Object) 实现，违反 Java 的重写语义。
C#具象化泛型天然保持方法签名一致性
C# 泛型在运行时保留类型信息，List<int></int> 和 List<string></string> 是两个独立的、真实存在的类型。编译器为每种类型参数生成专属的 IL 和运行时类型，因此：
-
Box<t>.Set(T)</t>在Box<string></string>中仍是Set(string)，签名未变 -
Box<string></string>继承Box<object></object>？不成立——C# 中泛型类型之间没有继承关系，不存在“向上转型后调用被擦除父类方法”的场景 - 所有泛型实例的方法表（vtable）都是完整且自洽的，无需额外方法来“补全”重写关系
设计目标差异决定机制取舍
Java 选择类型擦除，是为了零成本兼容 JDK 1.4 及更早的 JVM 字节码规范；C# 从 CLR 2.0 起就原生支持泛型，可以将类型实参作为元数据嵌入运行时。
- Java 的桥接方法是编译器对擦除缺陷的被动修补，属于“向后兼容的代价”
- C# 不需要桥接，因为它的泛型不是语法糖，而是运行时一等公民——
typeof(List<int>)</int>和typeof(List<string>)</string>返回完全不同 Type 对象 - 这也解释了为什么 C# 支持
new T()（有约束时）、typeof(T)、运行时反射获取泛型实参，而 Java 在运行时完全丢失这些信息
一个直观对比：子类重写的字节码表现
假设都定义 class Box<t> { public void set(T t) {} }</t> 和 class StringBox extends Box<string> { @Override public void set(String s) {} }</string>：
-
Java 编译后：
StringBox类中实际存在两个set方法：一个是开发者写的set(String)，另一个是编译器注入的桥接方法set(Object)，后者仅做强制转换并委托给前者 -
C# 编译后：
StringBox不存在，因为 C# 不允许这样继承泛型类（除非显式构造封闭类型并用 newslot）。更常见的是直接使用Box<string></string>，其set方法签名就是set(string)，且该类型在运行时已确定，无擦除、无委托、无桥接
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
