PECS原则指导访问者模式中泛型安全设计：元素集合应声明为List<? extends Element>（Producer），Visitor作为Consumer不泛型化，visit方法必要时用? super确保类型兼容，避免误用Visitor<E extends Element>破坏双分派。
PECS 原则在访问者模式（Visitor Pattern）中并不直接作为设计规范出现，但它能自然地指导你如何安全地定义 accept 和 visit 方法的泛型参数，尤其当 Visitor 需要处理多种元素类型（如 ElementA、ElementB 继承自公共父类 Element）时。
为什么访问者模式容易遇到泛型类型不匹配问题
典型访问者模式中，每个元素实现 accept(Visitor v)，而 Visitor 定义多个重载的 visit(ElementA a)、visit(ElementB b)。若试图用泛型统一 Visitor 接口（例如 Visitor<T extends Element>），就会面临类型擦除和协变限制：Java 泛型不可协变，Visitor<ElementA> 不是 Visitor<Element> 的子类型，无法复用同一访问逻辑。
此时，PECS 提供的是**接口设计层面的约束直觉**：Visitor 是“消费者”——它消费不同类型的元素；而被遍历的元素集合（如 List<? extends Element>）是“生产者”——它向外提供元素。
元素集合应声明为 ? extends Element（Producer）
当你用一个统一的 Visitor 处理异构元素列表时，该列表通常是 List<Element> 或其子类型集合。为支持多态传入（如 List<Dog>、List<Cat>），应将方法参数声明为：
立即学习“Java免费学习笔记（深入）”；
void traverse(List<? extends Element> elements, Visitor visitor)- 这样允许传入
List<Dog>、List<Cat>、List<Element>等，且可在循环中安全读取每个元素为Element类型 - 但禁止向该集合添加任何新元素（包括
new Element()），因为编译器无法确认实际运行时类型是否兼容
Visitor 接口本身通常不用泛型通配符，但 visit 方法可按需使用 ? super
标准 Visitor 接口是具体类型重载的，不依赖泛型通配符。但在某些泛化场景下（如通用工具类中的 visitAll 方法），若需让 Visitor 能接收更宽泛的输入（比如既能处理 Dog，也能处理其父类 Animal），可对参数使用 ? super Dog：
<T> void visitAll(List<T> items, Consumer<? super T> action)- 这等价于 PECS 中的 “Consumer Super”：action 是消费者，应能接受
T及其任意父类型，从而兼容更广的处理器（如Consumer<Animal>可用于List<Dog>） - 注意：这不是 Visitor 接口本身的泛型化，而是对其使用方式的类型安全增强
避免常见误用：不要给 Visitor 接口加 <? extends Element>
有人尝试定义 interface Visitor<E extends Element> 并让每个实现绑定一种 E，但这会破坏 Visitor 的核心价值——统一访问不同元素。结果是：
- 必须为每种子类型写一个 Visitor 实现，丧失双分派优势
- 无法用同一个 Visitor 实例遍历
List<? extends Element>，因Visitor<Dog>和Visitor<Cat>互不兼容 - 违背 PECS 直觉：Visitor 的职责是消费，不是产出类型参数；强行泛型化反而增加类型耦合
本质上，访问者模式与 PECS 不是强绑定关系，但当你把元素集合当作数据源（Producer）、把 Visitor 的处理行为当作消费动作（Consumer）时，PECS 就成了校验类型边界是否合理的快捷标尺——读取用 extends，写入或回调用 super，不读不写就不用通配符。
