Java泛型擦除下，中间件响应器需用ParameterizedType或TypeReference构造带实参的Type实例以支持任意ResponseDTO<T>反序列化；应拆分接口避免Void语义污染，并在上下文传递Type实现类型安全。
Java 中泛型本身不保留运行时类型信息，但中间件响应器要实现「高度通配」——即对任意业务响应结构（如 ResponseDTO<User>、ResponseDTO<List<Order>>）都能统一处理并正确反序列化——关键不在泛型声明本身，而在利用 ParameterizedType 手动构造带实参的类型引用。
用 ParameterizedType 构造可反射的响应类型
中间件响应器通常接收原始 JSON 字符串，需将其反序列化为具体业务类型。若只传 Class<ResponseDTO>，Jackson/Gson 无法知道 T 是 User 还是 Void。必须显式构造参数化类型：
- 定义工具类封装
ParameterizedTypeImpl（JDK 自带接口，需自行实现） - 调用方传入原始类（
ResponseDTO.class）和业务数据类型（User.class） - 组合成
ResponseDTO<User>的Type实例，供反序列化器使用
响应器接口设计避免 Void 语义污染
不要让中间件响应器强行承载「有参/无参」两种语义。比如 ResponseHandler<T, R> 中 R 为 Void 会导致调用时必须传 null，破坏空安全且逻辑含糊：
- 拆分为两个接口：
TypedResponseHandler<T>（带泛型响应体）和PlainResponseHandler（无泛型，返回简单成功/失败） - 前者用于需要反序列化业务数据的场景；后者用于健康检查、提交确认等无需解析 body 的操作
- 这样中间件链中每个处理器职责清晰，类型推导自然，不依赖运行时判空或强制转型
中间件链中传递类型上下文
在基于责任链或函数式链路的中间件中（如 Koa 风格），类型信息不能只靠方法签名维持。建议在请求上下文（Context）中携带 Type 实例：
立即学习“Java免费学习笔记（深入）”；
- 上游中间件（如路由解析器）识别目标接口后，将对应
ResponseDTO<X>的Type写入Context.attr("responseType") - 下游反序列化中间件读取该
Type，直接传给 Jackson 的mapper.readValue(json, type) - 避免每个处理器重复解析路径、硬编码类型，也规避了泛型擦除导致的 ClassCastException
配合 Jackson 的 TypeReference 简化调用
如果不想手写 ParameterizedTypeImpl，可借助 Jackson 提供的 TypeReference：
-
new TypeReference<ResponseDTO<User>>() {}—— 利用匿名子类保留泛型信息 - 注意：必须是匿名子类，仅 new TypeReference<>() 不行，否则仍被擦除
- 适合单点调用；若需动态构建（如根据字符串类名生成），仍需
ParameterizedType方案
