Java泛型不支持类声明中参数间直接依赖（如V extends K），但可通过泛型方法、共同上界、通配符等方式间接实现约束；例如方法签名中使用<K, V extends K>合法，而class Pair<K, V extends K>非法。
Java 中泛型本身不支持“参数间直接依赖”（比如 T 必须是 K 的子类），但可以通过类型边界嵌套 + 通配符 + 方法设计间接实现多个泛型参数之间的逻辑约束。关键不是让 T 依赖 K，而是让它们共用同一约束条件或通过方法签名强制关联。
✅ 用共同上界统一约束两个参数
当两个泛型参数需具备相同能力时，可让它们共享同一个带边界的类型变量：
public <T extends Comparable<T>> void sortPair(T first, T second) {
if (first.compareTo(second) > 0) {
// 交换逻辑
}
}这里 first 和 second 虽然都是 T，但本质是同一个类型变量，天然满足“可互相比较”。若你真需要两个不同参数名（如 K, V）却又要它们有关系，就得换思路。
✅ 让一个参数约束另一个：通过方法签名绑定
最实用的方式是——不靠类声明，而靠方法定义来建立参数间的类型契约：
立即学习“Java免费学习笔记（深入）”；
public class Mapper<K, V> {
// 显式要求 value 的类型必须能由 key 的类型推导/转换而来
public <R> R convert(K key, Function<K, R> converter) {
return converter.apply(key);
}
// 更强约束：要求 V 是 K 的某种“衍生类型”，例如 K 是 ID，V 是对应实体
public <T extends K> V mapToEntity(K key, Class<V> entityType) {
// 实际中可能查库、反射构造等
return null;
}
}注意：Java 不允许 class Mapper<K, V extends K> 这种写法（V extends K 在类声明中非法），但允许在方法级别这样写：
public <K, V extends K> void process(K base, V derived) {
// ✅ 合法：V 必须是 K 或其子类
System.out.println(base + " → " + derived);
}这是 Java 泛型中唯一支持跨参数继承约束的合法语法。
✅ 利用通配符 + 边界表达“兼容性”关系
当无法修改类结构时，可通过方法参数引入关联：
// 表示：source 集合里的元素类型，必须能赋值给 target 集合的元素类型
public static <T> void copy(List<? extends T> source, List<T> target) {
target.addAll(source); // 安全：子类型可转为父类型
}
// 调用示例：
List<String> src = Arrays.asList("a", "b");
List<Object> dst = new ArrayList<>();
copy(src, dst); // ✅ String 是 Object 子类，满足 ? extends Object这里 ? extends T 和 T 构成了一种隐含的“子类型→父类型”依赖，虽不是 K/V 直接约束，但实现了运行前可校验的类型兼容关系。
⚠️ 常见误区与限制
- ❌
class Pair<K extends Number, V extends K>是非法语法（Java 不允许在类声明中用一个类型参数约束另一个） - ❌ 不能写
V super K作为类泛型参数约束（super只用于通配符，如? super T） - ✅ 正确做法始终是：把复杂约束下沉到泛型方法中，而非类声明
? 实战建议：何时该用哪种方式？
- 如果只是“两个类型要能一起用”，比如键值对 → 用
Pair<K, V>，不加约束，靠业务逻辑保证 - 如果要求
V必须是K的子类 → 用泛型方法<K, V extends K> - 如果要求
K和V都能比较 → 共享<T extends Comparable<T>> - 如果要适配已有集合 → 用
<? extends T>/<? super T>控制读写边界
本质上，Java 泛型的“依赖”不是靠语法糖自动推导，而是靠开发者主动建模类型契约——把约束写进方法签名，比塞进类声明更灵活、更安全、也更符合类型擦除的实际机制。
