Java接口通过泛型约束在编译期锁定类型接受范围与操作能力，利用extends限定T必须满足的接口、基类或组合契约，使方法签名天然绑定泛型类型，并配合泛型函数式接口收紧策略类型链路，从而规避运行时类型错误。
Java 接口通过泛型约束，把“能接受什么类型”和“能做什么操作”在编译期就锁定，不是靠文档说明或运行时检查来兜底。
用 extends 明确限定可接受的类型范围
不加约束的泛型接口（如 interface Service<T>）等同于放行所有类型，容易导致逻辑错位或强转异常。加上 extends 后，编译器强制实现类或调用方提供符合行为契约的类型：
- 要求必须实现某个接口：
interface Service<T extends Identifiable & Serializable>，确保T既有唯一标识能力，又支持序列化 - 要求继承特定基类：
interface Repository<T extends BaseEntity>，让所有实体共享通用字段（如id、createdAt） - 组合多个约束：
<T extends Comparable<T> & Cloneable>，既可比较又可克隆，适合排序+副本场景
让方法签名与泛型类型联动
接口方法直接使用泛型参数，使操作语义天然绑定到类型上，避免转型和类型丢失：
-
T findById(Long id)—— 返回值就是调用方指定的T，无需强制转换 -
List<T> search(Query query)—— 结果列表自带类型，下游遍历时不会触发ClassCastException -
<R> R convert(Function<T, R> mapper)—— 输入始终是T，输出受R约束，类型链路清晰
配合函数式接口，把策略也泛型化
当服务需要外部传入处理逻辑时，用泛型函数式接口进一步收紧类型链路：
立即学习“Java免费学习笔记（深入）”；
- 定义：
@FunctionalInterface interface Validator<T> { boolean isValid(T obj); } - 服务方法：
<T> Result validate(T item, Validator<T> v) - 调用：
service.validate(user, u -> u.getEmail() != null && u.getAge() > 0)—— Lambda 参数类型自动推导为User，字段访问错误在编译期就能暴露
守住编译期边界，避开擦除陷阱
泛型擦除是运行时机制，不影响接口层面的类型安全设计，但实现细节需谨慎：
- 不能在接口实现里写
if (t instanceof T)—— 因为T已擦除，且本就不该在契约层做这种判断 - 不要依赖静态泛型方法承载核心契约逻辑 —— 静态方法无法感知实例的
T，容易绕过约束 - 实现类必须显式声明类型参数，例如
class UserService implements Service<User>；否则退化成原始类型，失去所有约束意义
