PECS原则是泛型设计准则，JavadocMethod仅校验注释格式完整性，不分析泛型语义，故不配置PECS；其职责是确保@param等标签存在且匹配，而非判断? extends或? super的使用合理性。
PECS 原则（Producer-Extends, Consumer-Super）本身是泛型使用的设计原则，与 Checkstyle 的 JavadocMethod 规则**没有直接配置关联**。
为什么 JavadocMethod 不配置 PECS？
JavadocMethod 是 Checkstyle 中用于校验方法 Javadoc 注释是否完整、格式是否合规的检查器，例如：是否缺失 @param、@return、@throws 等标签，以及参数名是否匹配、顺序是否正确等。
它不分析泛型语义，也不判断你该用 ? extends T 还是 ? super T——这属于代码逻辑和设计层面的职责，不在文档注释规范的校验范围内。
但你可以间接体现 PECS 在 Javadoc 中
虽然 Checkstyle 不强制要求写明“此参数遵循 PECS”，但良好的 Javadoc 应清晰说明泛型参数的用途，这恰好呼应 PECS 的意图：
立即学习“Java免费学习笔记（深入）”；
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 若参数是
List<? extends Animal>（生产者），Javadoc 可写：@param animals 要遍历的动物列表，支持 Animal 及其任意子类型（如 Dog、Cat） - 若参数是
List<? super Dog>（消费者），Javadoc 可写：@param targets 接收 Dog 实例的容器，可为 List<Dog>、List<Animal> 或 List<Object>
这类描述能帮助调用方理解为何这样设计，也便于后续工具（如 IDE 提示、静态分析插件）做语义推断。
Checkstyle 如何真正支持泛型文档？
Checkstyle 本身不解析泛型边界语义，但可通过以下方式增强泛型相关 Javadoc 质量：
- 启用
allowMissingParamTags设为false，确保每个泛型形参（如<T extends Comparable<T>>中的T）都有对应@param T说明 - 配合
AtclauseOrder检查器，规范@param标签顺序，使泛型类型参数与实际方法参数一一对应 - 使用自定义 Checkstyle 模块（需扩展 JavaParser）或搭配其他工具（如 ErrorProne、SonarJava）补充语义级检查
注意：标准 Checkstyle 不识别 ? extends 或 ? super 的语义，也不会因违反 PECS 报错——那是编译器和开发者共同的责任。
归根结底，PECS 是编码实践准则；Javadoc 是沟通载体；Checkstyle 是文档格式守门人。三者各司其职，协同提升可维护性。
