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