CuratorOp 不适用 PECS 原则，因其非泛型接口、无类型参数与子类体系，事务集合直接使用 Collection<CuratorOp> 具体类型，不涉及元素读写泛型语义，本质是命令模式而非数据容器。
Java 中 PECS 原则在 ZooKeeper CuratorOp 事务操作集合构建中，不直接适用，也不被 Curator 框架设计所采用。
原因很明确：CuratorOp 不是泛型集合（如 List<T>），而是一个无类型参数的接口，其核心作用是封装单个 ZooKeeper 原子操作（如 create()、setData()、delete()），本身不承载元素读写语义；它参与构建的事务容器 Collection<CuratorOp> 也未使用通配符泛型约束，而是直接声明为 Collection<CuratorOp> —— 即使用具体类型，而非 ? extends CuratorOp 或 ? super CuratorOp。
我们来分点说明：
CuratorOp 本身不是泛型类型
CuratorOp 是一个标记接口（marker interface），定义在 org.apache.curator.framework.api.transaction 包中，没有类型参数，也不继承或实现任何泛型父类。它的实现类（如 CreateBuilderImpl 返回的 CuratorOp 实例）是运行时生成的、类型擦除后的操作对象，不具备“生产元素”或“消费元素”的泛型集合行为。
立即学习“Java免费学习笔记（深入）”；
transaction().op(...) 构建的是具体类型集合
Curator 的事务 API 典型用法如下：
Collection<CuratorOp> ops = Arrays.asList(
client.create().forPath("/a", "1".getBytes()),
client.setData().forPath("/b", "2".getBytes())
);
client.transaction().op(ops).commit();这里 ops 是 Collection<CuratorOp>，所有操作都统一为 CuratorOp 类型。你无法传入 List<CreateBuilderImpl> 或子类集合——因为 CuratorOp 没有有意义的子类型体系（所有实现均通过内部代理构造，用户不可扩展），也就不存在协变/逆变需求。
PECS 的前提条件未满足
PECS 原则生效需同时满足两个前提：
- 存在泛型类型参数 T（如
List<T>） - 存在多态类型层级（如
Apple extends Fruit），且方法需兼容不同子类型集合的传入/传出
而 CuratorOp：
- 无类型参数 → 无
T可延伸或上界约束 - 无公开子类继承体系 → 不存在
? extends CuratorOp的实际意义（所有实例都是同一运行时类型） -
op(Collection<CuratorOp>)方法签名接受具体类型，不开放通配符重载
对比：标准库中真正用到 PECS 的场景（如 Collections.copy）
那才是典型 PECS 应用：
-
src是List<? extends T>→ 只读，确保能安全取出T -
dest是List<? super T>→ 只写，确保能安全存入T
这依赖于T的真实继承关系（如Integer extends Number）和集合对元素的读/写分离语义。
Curator 的 CuratorOp 集合既不读取元素内容用于业务逻辑（不遍历取值做转型），也不向集合中“添加任意子类型”（所有操作必须显式构造并转为 CuratorOp），因此没有引入通配符的动机与收益。
本质上，CuratorOp 是命令模式（Command Pattern）的轻量实现，关注的是操作序列的编排与执行，而非类型安全的数据流转 —— 它绕过了泛型集合的读写边界问题，自然也不需要 PECS。
不复杂但容易忽略：PECS 是泛型集合读写意图驱动的设计原则，不是所有带“集合”二字的地方都要套用。
