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