ClassFanOutComplexity按类实际依赖的具体类型数量统计，泛型参数<T>不计入；仅当引用、实例化或声明非泛型字段（如UserService）、方法参数/返回值使用具体类（如Order）、new对象（如EmailSender）或泛型边界含具体类（如ConfigService）时才计数。
ClassFanOutComplexity（类的分散复杂度）在泛型类中依然按“该类直接依赖的其他类数量”来统计，与泛型参数本身是否为类型变量无关；它只关心实际被引用、实例化或作为字段/参数/返回值出现的具体类型。
泛型类中 ClassFanOutComplexity 的真实计算逻辑
Checkstyle 不把 <T>、<E extends List<String>> 这类类型形参计入 Fan-Out。只有当泛型类中出现如下情况时，才会增加计数：
- 声明了非泛型字段，如
private UserService userService; - 方法参数或返回值使用了具体类型，如
public ResponseDto process(Order order) - 在方法体内 new 出其他类，如
new EmailSender().send(); - 静态导入或直接调用工具类，如
StringUtils.isEmpty(name) - 泛型边界中出现的具体类，如
class Processor<T extends ConfigService>—— 此处ConfigService算一次依赖
注意：List<String> 中的 List 和 String 都是 JDK 类，通常被排除在 Fan-Out 统计之外（取决于配置中的 excludeClassesRegexps 属性），但自定义类型如 Order、UserDto 会被计入。
泛型带来的常见误判场景及应对
以下写法看似“泛型很重”，实则不增加 Fan-Out：
立即学习“Java免费学习笔记（深入）”；
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
-
private final Map<String, List<Product>> cache;—— 只算Map和Product（若Product是自定义类） -
public <R> R convert(Object source, Class<R> targetType)—— 类型参数R不计入，但Class是 JDK 类，默认不计 -
extends Repository<User, Long>—— 若Repository是抽象基类或接口，且已存在于继承链中，Checkstyle 默认不重复计数（仅首次引用算一次）
真正拉高 Fan-Out 的，往往是泛型类内部“悄悄引入”的新业务类型，比如为了兼容多种数据源，在方法里新增了 KafkaProducer、RedisTemplate、MetricsService 等字段或调用。
优化泛型类 Fan-Out 的实用方式
目标不是删掉泛型，而是收敛依赖来源：
- 把高频使用的外部服务抽成统一接口（如
DataClient），由子类或策略实现，主泛型类只依赖该接口 - 用构造函数注入替代字段直接 new，把依赖显式暴露出来，便于识别和裁剪
- 对泛型类做职责切分：将“编排逻辑”（高 Fan-Out）与“类型处理逻辑”（低 Fan-Out）拆到不同类中
- 检查
checkstyle.xml中是否配置了合理的排除项，例如：
<property name="excludeClassesRegexps" value="^java\.|^\s*org\.slf4j\.|^javax\." />
配置与验证建议
在 checkstyle.xml 中明确控制上限，并启用详细日志定位高 Fan-Out 原因：
- 设置合理阈值：
<module name="ClassFanOutComplexity"><property name="max" value="8"/></module> - 配合
-v参数运行命令行版 Checkstyle，查看每个类的 Fan-Out 分解列表 - 在 IDEA 中启用 “Show violation details” 查看具体哪些类型被计入，避免误判第三方 SDK 内部类
泛型本身不是复杂度的根源，关键在于泛型容器里装了什么——看清依赖，比改泛型更重要。
