泛型方法<T extends 接口>返回值与直接返回接口是否等价

首先给出两种写法的代码示例：
第一种泛型方法定义：

<T extends SomeInterface> T method() {
    // 方法实现逻辑
}

第二种直接返回接口的方法定义：

SomeInterface method() {
    // 方法实现逻辑
}

核心区别 #

• 调用方使用成本和类型安全度完全不同
  第二种写法的编译期返回值类型固定是SomeInterface，调用方如果要使用具体实现类的自定义方法，必须手动强转。编译器不会校验强转的类型是否和方法实际返回的对象匹配，一旦强转错了，就会在运行时抛出ClassCastException。
  第一种泛型写法支持调用方直接指定期望的返回值具体类型，不需要手动强转，编译器会在编译阶段尽可能做类型校验。比如存在两个实现类UserService implements SomeInterface、OrderService implements SomeInterface，调用泛型方法时可以直接写：

  UserService userService = method();
  

  不需要加任何强转语法。如果是第二种返回接口的写法，上面的代码会直接编译报错，必须改成带强转的写法：

  UserService userService = (UserService) method();
  

  这行代码哪怕方法实际返回的是OrderService实例，编译阶段也不会报错，只有运行到这行的时候才会崩溃。

• 类型绑定能力不同
  泛型参数T可以和方法的其他参数、方法内部的逻辑做类型绑定，实现全链路的类型安全校验，这是直接返回接口的写法做不到的。最常见的场景就是传入具体类型的Class对象，保证返回值和传入类型匹配：

  <T extends SomeInterface> T getService(Class<T> serviceClass) {
      // 比如从IOC容器里取对应类型的实例
      return context.getBean(serviceClass);
  }
  

  调用这个方法时传入UserService.class，编译器自动推断返回值是UserService类型，直接赋值没有任何风险。如果换成返回SomeInterface的写法，还是绕不开手动强转。

对初步思考的纠正 #

认为两种写法都支持在子类中更具体地指定返回值类型，这个认知是有偏差的：
普通接口返回值的方法，子类重写时可以用Java的协变返回值特性，把返回值改成具体实现类，但这个类型收窄只在你用子类类型引用调用方法时生效，用父类类型引用调用时，编译期类型还是SomeInterface。而泛型方法的类型灵活性是在方法调用时就生效的，不需要依赖子类重写。

另外要注意：示例里的无参泛型方法其实是有设计缺陷的——没有任何入参能帮编译器推断T的实际类型，调用方可以随便给T传任何实现了SomeInterface的类型，方法实现如果没法保证返回值匹配任意可能的T，依然会出现运行时类型转换异常。这种无参、仅返回值用泛型的写法，如果没有特殊逻辑支撑，反而不如直接返回SomeInterface更清晰。

选型参考 #

如果方法返回的对象只需要暴露SomeInterface中定义的接口方法，调用方不需要感知具体实现类，直接返回接口类型就足够，写法更简洁。
如果方法需要支持调用方获取具体实现类型、避免手动强转，或者需要把返回值类型和方法参数、内部逻辑做类型绑定，就必须用泛型的写法。

内容的提问来源于stack exchange，提问作者xtay2