PECS原则不直接体现在ObjectMapper.convertValue方法签名中，因其面向单对象类型转换而非泛型集合操作；但结合PECS可安全处理集合元素的转换与存取，避免类型误用。
Java中 PECS原则并未直接体现在 Jackson 的 ObjectMapper.convertValue 方法签名中，因为该方法本身不操作泛型集合，而是面向类型转换——它接收一个源对象和目标类型，不涉及“读取多个元素”或“批量写入容器”的集合流转场景。但理解 PECS，能帮你更安全、更合理地使用 convertValue 配合泛型集合，避免常见误用。
convertValue 本身不遵循 PECS，因为它不是集合操作
ObjectMapper.convertValue(Object from, Class<t> to)</t> 或 convertValue(Object from, TypeReference<t> to)</t> 的设计目标是单对象类型转换：把一个 Java 对象（或 JSON 节点）转成指定的 Java 类型。它不接收 List<? extends Person> 这类通配符集合，也不向集合里 add 或 get 元素。所以它的参数没有 ? extends 或 ? super ——它只关心“从什么转成什么”，而不是“谁在读、谁在写”。
但你常在 PECS 场景里调用 convertValue
真实业务中，convertValue 往往嵌套在泛型集合处理流程中。这时 PECS 决定的是上游集合怎么传进来、下游集合怎么接住结果，而 convertValue 是中间加工环节：
- 比如要把
List<Student>中每个元素转成Person，再塞进List<Person>：你该用List<? extends Student>接收源列表（只读），用List<? super Person>接收目标列表（只写），循环中对每个student调用mapper.convertValue(student, Person.class) - 若错误地把目标声明为
List<Person>，就无法接收List<Object>或List<Serializable>；若源用List<Person>，就传不进List<Student>——这些限制与convertValue无关，但影响它能否被顺畅调用
避免把 convertValue 当作“类型擦除兜底方案”
有人试图绕过 PECS 约束，比如：
立即学习“Java免费学习笔记（深入）”；
- 把源集合声明为
List<Object>，再对每个元素convertValue(obj, Target.class)——这看似灵活，实则放弃编译期类型检查，运行时可能因字段不匹配失败 - 用
convertValue(list, new TypeReference<List<Person>>(){})批量转换，但若原始list是List<Student>，Jackson 仍会按Student的序列化结构反推，未必能正确映射到Person字段
真正安全的做法是：先用 PECS 明确集合边界，再对每个兼容元素做精准转换。例如：
public static <T> void convertAndAdd(List<? extends Object> src, List<? super T> dest, Class<T> targetType, ObjectMapper mapper) {for (Object item : src) {
T converted = mapper.convertValue(item, targetType);
dest.add(converted); // ✅ PECS 保证 add 安全
}
}
总结：PECS 管边界，convertValue 管转换
convertValue 是类型转换工具，PECS 是集合协作契约。前者解决“怎么变”，后者解决“从哪来、到哪去”。你在设计泛型集合处理方法时，用 PECS 声明参数类型，让 convertValue 在清晰的类型上下文中工作——这样既保编译安全，又免运行时异常，还不用写一堆 instanceof + 强转。
