统一结果返回类应以 apiresponse 为固定容器，data 字段用泛型 t 承载任意嵌套结构（如 pageresult），避免多层 wrapper；需限定上界、保留泛型信息、控制嵌套≤三层，并配合接口约束与 jackson 兼容设计。
统一结果返回类要真正支持任意业务数据的嵌套，关键不是“泛型能套多深”，而是让泛型结构贴合真实响应层级，同时避免类型擦除和误用包装。
用单层泛型承载整个 data 字段
不要给每个业务对象单独套 Wrapper，而是把 Wrapper 当作 HTTP 响应容器——data 是唯一可变部分：
-
正确写法：`ApiResponse
`、`ApiResponse - >`、`ApiResponse
>`，其中 `PageResult ` 本身也是泛型类，形成自然嵌套 -
错误写法：`Wrapper
- >>` —— 这会导致 runtime 类型丢失、JSON 反序列化失败、前端解析混乱
- 定义时明确 data 字段为泛型：`private T data;`，而非 `private Object data` 或 `private Map
data`
允许 data 类型本身就是泛型结构
Java 泛型支持类型参数是另一个泛型类型，只要调用方明确指定即可：
- 例如 `ApiResponse
>`：外层 `ApiResponse` 管理 code/message，中间 `PageResult` 封装 total/pageNo/content，内层 `UserProfile` 是具体业务模型 - 再如 `ApiResponse
- Spring MVC 能自动识别并完成 Jackson 反序列化，前提是类有无参构造器 + 标准 getter
配合接口约束提升编译期安全性
单纯靠 `
- 定义 `ApiResponse
`，强制所有业务返回体实现 `ResponseData` 接口（含 `getTraceId()`、`isSuccess()` 等通用能力） - 导出任务统一用 `ApiResponse
>`，确保 `T` 具备 `toExcelRow()` 方法，避免运行时转型异常 - 批量操作返回 `ApiResponse
>`，两个类型参数分工清晰：ID 用于标识成功项，Error 用于描述失败原因
注意反序列化与可读性的平衡
嵌套过深会增加 JSON 解析负担和调试成本，建议控制在三层以内：
- 推荐结构：`ApiResponse` → `PageResult` / `Map` / `List` → 具体业务对象（如 `User`、`OrderItem`）
- 避免四层以上嵌套，例如 `ApiResponse
- >>>>>` —— 此时应拆分为独立 DTO 或引入中间视图类
- Lombok 的 `@Data` 和 Jackson 的 `@JsonCreator` 可简化嵌套类型的构造与序列化，但需确保泛型信息在字节码中保留（避免仅靠运行时反射）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
