Java泛型擦除不可逆，所谓“还原运行时异常DTO”是概念错误；真实问题是JSON反序列化时泛型类型信息缺失导致ClassCastException，应通过TypeReference、具体子类或简化DTO结构解决。
这个问题存在概念混淆——“还原运行时异常 DTO”并不是一个标准技术目标，也不符合 Java 泛型擦除与异常处理的底层逻辑。我们来理清关键点：
泛型擦除本身不产生异常，也不会“丢失 DTO”
泛型擦除是编译期行为，它抹去的是类型参数（如 List 中的 UserDTO），但不会影响 DTO 类本身的字节码、字段或运行时存在。DTO 对象（如 new UserDTO()）始终是完整可实例化的普通类，擦除不影响其构造、序列化或作为异常载荷的能力。
所谓“异常 DTO”，通常指用于封装错误响应的业务对象，例如：
public class ErrorResponse {
private int code;
private String message;
private Object details; // 可能是泛型数据，如 List<validationerror>
}
</validationerror>
真正需要解决的是：泛型字段在反序列化时因擦除导致类型丢失
典型场景是 JSON 反序列化异常响应体中的泛型字段，例如：
{
"code": 400,
"message": "Validation failed",
"details": [{"field":"email","error":"invalid format"}]
}
若你用 ErrorResponse 接收，却只传 >
ErrorResponse.class，Jackson/Gson 会把 details 解析为 LinkedHashMap，而非 List —— 这不是异常，而是类型信息缺失引发的 运行时 ClassCastException 或空指针，常在后续访问 details.get(0).getField() 时暴露。
解决方法不是“还原异常 DTO”，而是确保泛型结构在反序列化时被正确捕获：
- 用
TypeReference（Jackson）或TypeToken（Gson）显式传递完整泛型签名：objectMapper.readValue(json, new TypeReference>>() {}) - 若异常响应结构固定，可定义非泛型的具体类型：
public class ValidationErrorResponse extends ErrorResponse，再传- > {}
ValidationErrorResponse.class - 对 details 字段使用
@JsonUnwrapped或自定义JsonDeserializer，绕过泛型解析，手动构建列表
异常处理应聚焦真实错误流，而非“恢复擦除”
泛型擦除不可逆，也不该由异常处理机制去“还原”。正确的做法是：
- 在反序列化入口处做防御性检查：捕获
JsonProcessingException，记录原始 JSON 和失败位置，返回统一ErrorResponse给前端 - 避免在 catch 块中尝试“修复”类型，例如把
LinkedHashMap强转成ValidationError—— 这只会掩盖问题，导致更难排查的ClassCastException - 将 DTO 验证前移：用
@Valid+@Validated在 Controller 层拦截非法输入，减少下游因类型错配触发的异常
DTO 设计本身可降低泛型异常风险
与其在异常路径上硬扛复杂泛型，不如简化结构：
- 用
record定义不可变错误详情（Java 14+）：public record ValidationError(String field, String error) {}，序列化/反序列化更稳定 - details 字段声明为
List或JsonNode，放弃强类型，换取灵活性 - 采用密封类（sealed class）建模不同错误形态，配合模式匹配处理，避免泛型嵌套：
sealed interface ApiError permits ValidationError, AuthError, SystemError
