关键在于用pojo建模+jackson序列化实现可读、可维护的嵌套json：按业务语义拆分orderresponse、addressdto、itemdto等类，配合@jsoninclude、@jsonproperty等注解控制序列化，并统一封装为result响应体。
关键不在“嵌套多深”，而在于结构是否可读、可维护、可预期。用好 POJO 建模 + Jackson 序列化，配合分层设计和合理注解，就能让嵌套 JSON 清晰自然，不靠拼字符串、不靠手动构造 JsonNode。
按业务语义建模嵌套结构
不要把所有字段塞进一个大类里，而是拆解成符合真实业务关系的嵌套类。比如订单响应中，“收货地址”“商品列表”“优惠明细”应各自独立成类，并作为主订单对象的字段：
- 定义 OrderResponse 类，含 id、status、address（AddressDTO 类型）、items（List
）等字段 - AddressDTO 封装 province/city/detail 等字段，不暴露实体类的 JPA 注解或内部 ID
- ItemDTO 只保留前端需要的 skuName、quantity、price，避免传入库存、成本等敏感字段
用 Jackson 注解控制序列化行为
默认序列化容易暴露不该返回的内容，或漏掉关键字段。几个常用且实用的注解：
- @JsonInclude(JsonInclude.Include.NON_NULL)：全局或类级别配置，自动跳过 null 字段，避免响应中出现 "address": null
- @JsonProperty("user_name")：精准匹配前端约定的下划线命名，无需改 Java 字段名
- @JsonIgnore：标记密码、创建时间戳等敏感或冗余字段，不参与序列化
- @JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss")：统一日期格式，避免前端解析失败
响应体统一包装，嵌套结构更可控
直接返回 OrderResponse 容易导致各接口风格不一致。建议外层统一封装为 Result
- Result 类包含 code、message、data、timestamp 四个字段，data 泛型即为 OrderResponse
- 这样无论返回单个对象、列表还是深度嵌套结构，外层协议完全一致，前端可复用解析逻辑
- 配合 @ControllerAdvice 全局处理异常，确保所有接口都走同一响应模板，不会出现有的返回 {data:{...}}，有的直接返回 {...}
避免运行时动态拼装 JSON
别在 Controller 里 new ObjectMapper().valueToTree() 或手写 JSONObject.put(...) 来组装嵌套结构。这类写法：
- 字段名硬编码，重构时极易出错
- 类型转换无保障，number 写成字符串、null 被忽略等问题频发
- 无法享受 IDE 自动补全、编译期校验、单元测试覆盖
- 一旦嵌套层级增加（如 items → subItems → attributes），代码迅速失控
坚持“对象即结构”，让 Jackson 在序列化阶段自动完成嵌套展开，才是可持续的做法。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
