PECS原则在模板方法钩子函数中仅作用于泛型参数设计：入参作为消费者应声明为? super T，返回值或产出容器作为生产者应声明为? extends T；非泛型钩子无需考虑PECS。
PECS（Producer Extends, Consumer Super）原则在模板方法模式中不直接作用于钩子函数本身，而是影响其参数类型的设计——尤其当钩子方法接收泛型集合或回调上下文作为输入时。
钩子函数参数常需作为“消费者”处理数据
钩子方法（如 shouldExecute()、beforeProcess(T context)）通常用于干预流程，其入参往往是运行时传入的具体上下文对象。此时参数是被模板方法“消费”的，应遵循 Consumer Super：
- 若钩子方法需兼容多种子类型上下文（如
BaseContext及其子类OrderContext、PaymentContext），声明为beforeProcess(? super BaseContext)更安全； - 避免写成
beforeProcess(? extends BaseContext)——这会让方法只能接收更宽泛的父类型（如Object），失去类型约束，实际无法使用子类特有字段； - 典型场景：抽象模板中定义
protected void beforeSubmit(Request> request)，子类覆盖时可接受任意Request子类实例，无需强制泛型协变。
返回值或泛型容器参数可能涉及“生产者”视角
少数情况下，钩子方法返回一个泛型结果（如 List<?> 或 Optional<T>），或接收一个用于填充结果的容器参数：
Java注释规范Skills
下载
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
- 若钩子负责生成某种结果（如
collectMetrics()返回指标列表），返回类型宜用List<? extends Metric>（Producer Extends），方便子类返回LatencyMetric等具体子类； - 若钩子接收一个待填充的集合（如
addExtraHeaders(List<String> headers)），参数应声明为List<? super String>，确保能向任意String容器（如ArrayList<CharSequence>）安全写入； - 但实践中，这类设计较少见——钩子方法更倾向无参、布尔返回或简单上下文入参，过度泛化反而降低可读性。
多数钩子无需泛型，PECS 仅在必要时介入
标准模板方法中的钩子（如 boolean shouldSkip()、void afterSave()）本身不带泛型参数，PECS 不生效。只有当钩子明确参与泛型数据流转时才需考虑：
立即学习“Java免费学习笔记（深入）”；
- 优先用具体类型（如
beforeValidate(OrderRequest req)），清晰且类型安全； - 仅当框架需高度通用（如统一处理各类
Event<T>），才引入通配符，并严格按 PECS 判定方向； - 误用
extends作入参会导致编译错误（无法调用子类特有方法），误用super作返回值会限制子类自由度（只能返回Object等顶层类型）。
