Dubbo接口参数声明为List<? extends BaseParam>会导致反序列化失败，根本原因是Hessian2等序列化器无法还原泛型擦除后的具体子类型；正确做法是改为List<BaseParam>或定义明确DTO类，并确保子类具备无参构造函数、字段可序列化及serialVersionUID稳定。
当 Dubbo 接口参数声明为 List<? extends BaseParam> 时，服务端常出现反序列化失败、空列表、类型转换异常或 ClassCastException，根本原因不是写法本身错误，而是 Dubbo（尤其 Hessian2 默认序列化器）无法在运行时还原泛型擦除后的具体子类型。
泛型信息在 RPC 传输中彻底丢失
Dubbo 序列化过程不保留 Java 泛型的类型参数（如 ? extends BaseParam），只保留原始类型 List 和元素的**实际运行时类名**。但若客户端传的是 ArrayList<SubParam1>，服务端反序列化时仅知道是 List，却不知道每个元素该实例化成 SubParam1 还是 SubParam2——除非显式提供类型线索。
- Java 编译后泛型被擦除，
List<? extends BaseParam>在字节码中等价于List - Hessian2 默认按
BaseParam.class尝试构造元素，若子类有额外字段或构造逻辑，就会失败或丢数据 - Fastjson2 或 Kryo 等序列化器同样无法自动推断通配符边界，需人工干预
服务端必须声明具体实现类型
接口定义应避免使用通配符上界作为远程参数类型。Dubbo 调用链要求两端对“可序列化的类型”达成精确一致，而 ? extends 是编译期约束，不参与序列化协议协商。
- ✅ 正确做法：将参数改为
List<BaseParam>，并在BaseParam中定义所有子类共有的字段；子类字段通过继承+反序列化兼容设计承载 - ✅ 更稳妥做法：定义明确的 DTO 类，如
UserCreateRequest，内部用List<UserDetail>，而非泛型通配 - ❌ 不推荐：保留
List<? extends BaseParam>并依赖自定义反序列化器——维护成本高且易出错
确保子类具备反序列化必需条件
即使改成 List<BaseParam>，若子类未正确适配，仍会出问题。关键检查点：
立即学习“Java免费学习笔记（深入）”；
- 所有可能出现在列表中的子类（如
SubParam1、SubParam2）都必须有 public 无参构造函数 - 子类需继承
BaseParam且不能使用transient或static修饰待传输字段 - 确认子类与
BaseParam的serialVersionUID保持稳定（尤其升级时） - 若用 Hessian2，子类不能含 JDK 8+ 新增的不可序列化类型（如
Optional、LocalDateTime），需转为String或long
启用调试与验证手段
快速确认是否为泛型反序列化问题：
- 在 Provider 端方法入口加日志：
log.info("Received list: {}, type: {}", list, list.getClass().getComponentType()); - 开启 Dubbo 序列化日志：
-Ddubbo.serialize.logger=slf4j -Ddubbo.codec.logger=slf4j - 对比 Consumer 发送的 JSON（如用泛化调用）与 Provider 接收后对象的实际字段值，看是否有字段为空或类型错乱
- 临时改用
@DubboService(version = "1.0", serialization = "fastjson2")测试，Fastjson2 对继承体系支持更透明
