PECS原则通过extends和super限定泛型边界解决Java泛型不变性问题：读取用? extends T支持协变，写入用? super T支持逆变，实现API与业务类型结构的松耦合适配，全程编译期类型安全。
PECS 原则直接解决 Java 泛型不变性带来的 API 绑定过死问题，让 SDK 和第三方库不再强制调用方“削足适履”，而是主动适配业务已有的类型结构。
避免因泛型不变性导致的强制转换或复制
Java 中 List<String> 不是 List<Object> 的子类型，哪怕 String 是 Object 的子类。如果 SDK 方法写成 void process(List<Order> orders)，而业务端实际持有 List<PayOrder>（PayOrder 继承自 Order），就只能手动遍历复制——既低效又破坏语义。使用 Iterable<? extends Order> 后，传入 List<PayOrder>、Set<RefundOrder> 或 Stream<Order>.toList() 全部合法，无需额外转换。
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
让写入类 API 支持更宽泛的目标容器
当 SDK 提供批量填充能力（如查询结果写入已有集合），用 Collection<? super Order> 作为参数，调用方可传入：
• ArrayList<Order>
• LinkedList<Serializable>（因为 Order 实现了 Serializable）
• CopyOnWriteArrayList<Object>
SDK 内部可安全调用 target.add(new PayOrder())，但读取时只按 Object 处理——这是类型安全的代价，换来的是调用方零改造。
组合读写场景下保持两端松耦合
通用转换器、序列化器、校验聚合器等中间能力，常需同时读源、写目标。例如：<S, T> void transform(Iterable<? extends S> src, Collection<? super T> dst, Function<S, T> mapper)
• src 可接受 List<UserV1>、Stream<UserDTO> 等任意 S 子类型集合
• dst 可指向 ArrayList<Entity>、ConcurrentLinkedQueue<Object> 等任意 T 父类型容器
业务升级 DTO 层或调整领域模型时，SDK 调用代码完全不用动。
不依赖运行时反射，纯编译期类型保障
PECS 不是妥协，而是利用泛型擦除前的编译检查机制：方法签名中明确声明“只读”或“只写”，编译器自动拦截非法操作（如向 ? extends T 添加元素、从 ? super T 强转为具体子类）。这种约束在编译阶段就锁定行为边界，比运行时 instanceof + 强转更安全、更高效，也更利于 IDE 推导和文档生成。
