当 http 响应状态码非 200（如 400）时，jackson 默认仍会尝试将错误 json（如 {"error": {...}}）反序列化为业务 pojo，导致字段全为 null；正确做法是按状态码分支处理——仅对成功响应解析目标类型，否则解析专用错误结构。
当 http 响应状态码非 200（如 400）时，jackson 默认仍会尝试将错误 json（如 {"error": {...}}）反序列化为业务 pojo，导致字段全为 null；正确做法是按状态码分支处理——仅对成功响应解析目标类型，否则解析专用错误结构。
在使用 Jackson 进行 REST API 响应反序列化时，一个常见误区是「无差别调用 ObjectMapper.readValue()」，尤其当服务端返回错误响应（如 400 Bad Request）且 JSON 结构与业务模型完全不匹配时（例如：{"error": {"status": 400, "message": "invalid id"}}），Jackson 无法映射任何字段，最终返回一个所有字段均为 null 或默认值（如 0）的“空壳”对象——这不仅掩盖了真实错误，还极易引发后续 NPE 或逻辑异常。
根本解决方案：基于 HTTP 状态码做响应类型路由，而非依赖 Jackson 的容错配置（如 FAIL_ON_UNKNOWN_PROPERTIES）。Jackson 的配置仅控制字段级兼容性，无法解决「整个 JSON 结构语义不匹配」的问题。
✅ 正确实践如下：
-
定义专用错误响应模型（清晰分离关注点）：
@Getter public static class ErrorStatus { private int status; private String message; }
@Getter public static class ErrorResponse { private ErrorStatus error; }
2. **根据 HTTP 状态码动态选择反序列化目标类型**：
```java
int statusCode = response.code();
if (statusCode == 200) {
POJO pojo = mapper.readValue(response.body().string(), POJO.class);
// ✅ 安全使用业务对象
System.out.println("Success: " + pojo.getName());
} else {
// ❌ 避免用 POJO 解析错误响应
ErrorResponse errorResponse = mapper.readValue(response.body().string(), ErrorResponse.class);
System.err.println("API Error [" + statusCode + "]: " + errorResponse.getError().getMessage());
// 可抛出自定义异常，或返回 Optional.empty()
throw new ApiException(errorResponse.getError().getStatus(), errorResponse.getError().getMessage());
}⚠️ 注意事项：
- 不要试图通过 @JsonCreator、@JsonIgnoreProperties 或 DeserializationFeature.ACCEPT_SINGLE_VALUE_AS_ARRAY 等机制“强制适配”错误响应——这违背契约设计，增加维护成本；
- 若使用 Retrofit 或 Spring RestTemplate，建议封装统一的 ResponseHandler，将状态码判断和反序列化逻辑内聚；
- 对于严格契约 API，可配合 OpenAPI 规范生成类型安全的客户端，从根本上规避运行时类型错配。
总结：Jackson 是强大的序列化工具，但它不替代 HTTP 协议语义处理。将状态码判断前置，是构建健壮 REST 客户端的第一道防线。
