规范泛型接口实现需按职责选类型：单一用途用具体类型固化，如class idvalidator implements processor；通用能力须透传类型参数，如class cache implements supplier；子接口继承必须立即具体化父接口类型，如interface userprocessor extends processor。
规范泛型接口的实现标准，核心是让类型绑定在编译期就清晰、安全、可读——不是写对语法，而是选对类型。关键看实现类的职责：单一用途就固化类型，通用能力就透传类型，扩展接口就必须立即具体化。
非泛型实现类：用具体类型锁死契约
当一个类只处理一种数据（比如专做用户ID校验、只解析JSON字符串），就该把接口类型参数明确为实际业务类型。
- 写法：直接在 implements 后写出带实参的接口，如 class IdValidator implements Processor
- 效果：接口中所有
T全部替换为String，方法签名自动变成String process(String) - 禁止：
implements Processor（退化为原始类型，失去检查）或implements Processor>（语法不合法）
泛型实现类：类型参数必须透传对齐
如果实现类本身要支持多种数据（如通用缓存、统一响应包装器），它自己也得是泛型，并与接口共用同一个类型形参。
- 写法：class Cache
implements Supplier ，注意两边T名称和位置必须一致 - 逻辑：类型由使用者在创建实例时确定，例如
new Cache<integer>()</integer>，整条链路都按Integer校验 - 禁止：
class Cache<u> implements Supplier<t></t></u>（名称不一致，编译失败）
子接口继承：父接口类型必须当场填满
用 interface 扩展已有泛型接口时，不能继续留白，必须立刻指定父接口所需的类型实参。
- 允许：interface UserProcessor extends Processor
（明确子接口只服务 User） - 禁止：interface GenericProcessor
extends Processor （这不是继承，是重定义新接口） - 原因：Java 不支持“泛型接口的泛型继承”，子接口只能是具体化后的产物
类型选择要贴近业务真实约束
类型参数不是摆设，它应反映数据本质和调用习惯，避免为了泛而泛。
- 优先最小必要类型：处理订单号用
String，不必硬套T extends CharSequence - 避开无意义泛化：一个只存
Cat的仓库，声明成<t extends animal></t>反而增加理解成本 - 注意擦除影响：运行时拿不到
T的Class对象；若需反射或序列化，得额外传入Class<t></t>参数
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
