泛型接口实现需按场景选择类型固化或透传：非泛型实现类应明确指定具体类型如implements Processor<String>，泛型实现类须保持类型参数一致如class Cache<T> implements Supplier<T>，子接口继承时必须具体化父接口类型。
在泛型接口中规范实现类的类型，核心是让类型绑定清晰、安全、可维护——不是靠运行时检查，而是靠编译期强制约束。关键不在于“怎么写语法”，而在于“根据什么决定填哪个类型”。
非泛型实现类：直接固化一个具体类型
当实现类只服务单一业务场景（比如专处理用户ID字符串、固定解析JSON响应体），就该把接口的类型参数明确为一个具体引用类型。
- 写法：在 implements 后完整写出带类型实参的接口，如
implements Processor<string></string> - 效果：接口中所有
T全部被替换为String，方法签名自动变成String process(String) - 禁止省略：写成
implements Processor会退化为原始类型，失去类型检查；写成implements Processor>编译不通过
泛型实现类：透传类型参数，保持复用能力
若实现类本身需适配多种数据（如通用缓存容器、统一响应包装器），那就让它自己也带类型参数，并与接口对齐。
- 写法：声明为
class Cache<t> implements Supplier<t></t></t>，注意两边的T名称必须一致 - 逻辑：类型由使用者在创建实例时确定，如
new Cache<integer>()</integer>→ 整个链路都按Integer校验 - 避免混用：不能写成
class Cache<u> implements Supplier<t></t></u>，编译报错
子接口继承时：必须立即确定父接口类型
扩展已有泛型接口时，不能继续留白，必须当场填上父接口需要的类型实参。
立即学习“Java免费学习笔记（深入）”；
- 允许：定义
interface UserProcessor extends Processor<user></user>，这是明确契约 - 禁止：定义
interface GenericProcessor<t> extends Processor<t></t></t>，这不是继承，是重定义接口 - 原因：Java 不支持“泛型接口的泛型继承”，子接口只能是具体化后的产物
选类型要从实际出发，不是越泛越好
类型参数不是装饰，它应反映真实约束和使用意图。
- 优先最小必要类型：处理订单号就用
String，不需要硬套T extends CharSequence - 避开无意义泛化：一个只存
Cat的仓库类，声明成<t extends animal></t>反而增加调用方理解成本 - 注意擦除限制：运行时拿不到
T的 Class 对象，如需反射或序列化，得额外传入Class<t></t>参数
