当 http 响应状态码非 200（如 400 错误）时，jackson 默认会将不匹配的 json 反序列化为字段全为 null 的 pojo 实例；正确做法是根据状态码区分处理——成功时解析目标对象，失败时解析错误结构，从而避免“假成功”的空对象。
当 http 响应状态码非 200（如 400 错误）时，jackson 默认会将不匹配的 json 反序列化为字段全为 null 的 pojo 实例；正确做法是根据状态码区分处理——成功时解析目标对象，失败时解析错误结构，从而避免“假成功”的空对象。
在使用 Jackson 进行 REST API 响应反序列化时，一个常见误区是：未校验 HTTP 状态码就直接调用 ObjectMapper.readValue()。例如，当服务端返回 400 Bad Request 并附带如下 JSON：
{ "error": { "status": 400, "message": "invalid id" } }
而你却用 mapper.readValue(json, POJO.class) 强制解析，Jackson 因关闭了 FAIL_ON_UNKNOWN_PROPERTIES，且 JSON 中无 name/someString 字段，便会静默地为所有字段赋默认值（null、0、false 等），最终得到一个看似“成功”但实际无业务意义的空对象：POJO(name=null, someString=null)。
✅ 正确做法是：按 HTTP 状态码路由反序列化逻辑——仅当状态码为 200 OK（或其它约定的成功码，如 201）时，才解析为业务 POJO；否则，应解析为统一错误结构。
✅ 推荐实现方式
首先定义清晰的错误响应模型：
@Getter
public static class ErrorStatus {
private int status;
private String message;
}
@Getter
public static class ErrorResponse {
private ErrorStatus error;
}
然后在 HTTP 响应处理处做显式分支：
int statusCode = response.code();
if (statusCode == 200) {
POJO pojo = mapper.readValue(response.body().string(), POJO.class);
// ✅ 安全使用 pojo，字段已按预期填充
System.out.println("Success: " + pojo);
} else {
// ❌ 避免用 POJO.class 解析错误 JSON
ErrorResponse errorResponse = mapper.readValue(response.body().string(), ErrorResponse.class);
System.err.println("API Error [" + statusCode + "]: " + errorResponse.getError().getMessage());
// 可选择抛出自定义异常，或返回 null / Optional.empty()
return null; // 或 throw new ApiException(errorResponse);
}
⚠️ 注意事项
- 不要依赖 null 字段判断响应有效性：JSON 缺失字段 ≠ 响应错误；HTTP 状态码才是权威依据。
- 禁用 FAIL_ON_UNKNOWN_PROPERTIES 是合理配置（尤其对接多版本 API），但绝不意味着可忽略协议语义。
- 若需统一返回类型，建议封装为 Result
或使用 Optional ，而非让业务层自行判空。 - 生产环境建议配合 @JsonInclude(JsonInclude.Include.NON_NULL) 防止序列化冗余 null 字段。
通过状态码驱动反序列化策略，既符合 RESTful 设计原则，又能从根本上杜绝“幽灵空对象”，提升客户端健壮性与可维护性。
