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