本文介绍在 jackson 反序列化过程中，当 json 字段预期为 `int` 类型但实际返回非数字字符串（如 `"no number"`）时，通过自定义反序列化器将其安全转换为默认值（如 `0`）的完整实现方案，并探讨更健壮的建模替代方案。
在使用 Jackson 解析外部 API 返回的地址数据时，常会遇到类型不一致问题：例如 houseNumber 字段在 Java 中声明为 int，但 API 却可能返回 "NO NUMBER"、"123A" 或空字符串等非纯数字字符串，导致 JsonMappingException 报错。Jackson 默认不支持跨类型容错解析，需显式干预。
✅ 方案一：使用 @JsonDeserialize 自定义反序列化器
最直接且可控的方式是为 houseNumber 字段绑定一个轻量级自定义反序列化器：
@JsonInclude(JsonInclude.Include.NON_NULL)
public class Address implements Serializable {
private static final long serialVersionUID = -7134571546367230214L;
private String street;
@JsonDeserialize(using = HouseNoDeserializer.class)
private int houseNumber; // 注意：仍保持 int 类型，0 为兜底值
private String district;
private String city;
private String state;
private String zipCode;
}对应反序列化器实现如下（建议定义为静态内部类或独立工具类）：
public static class HouseNoDeserializer extends JsonDeserializer{ @Override public Integer deserialize(JsonParser p, DeserializationContext ctxt) throws IOException { // 统一按字符串读取，兼容数字字符串和任意文本 String raw = p.getValueAsString(); if (raw == null || raw.trim().isEmpty()) { return 0; } try { return Integer.parseInt(raw.trim()); } catch (NumberFormatException e) { // 日志可选：ctxt.handleWeirdStringValue(Integer.class, raw, "Invalid house number, defaulting to 0"); return 0; } } }
⚠️ 注意事项：
- p.getValueAsString() 比 p.readValueAs(String.class) 更安全，避免重复解析；
- 建议添加 trim() 防止 " 42 " 类空白干扰；
- 生产环境建议记录 WARN 级日志（通过 ctxt.handleWeirdStringValue 或 SLF4J），便于追踪脏数据来源；
- 此方案适用于必须保留 int 类型语义且仅需简单兜底（如统计/排序）的场景。
✅ 方案二（推荐）：语义建模升级 —— 改用 String + 后处理
从领域建模角度看，门牌号本质是标识符（identifier）而非纯数值："12B"、"S101"、"NO NUMBER"、"Ground Floor" 均合法。强行映射为 int 会丢失信息并增加维护成本。
优化后的设计如下：
public class Address implements Serializable {
// ... 其他字段不变
private String houseNumber; // ✅ 语义准确，兼容所有格式
// 可选：提供安全的数字提取方法
public Optional getHouseNumberAsInt() {
if (houseNumber == null) return Optional.empty();
String trimmed = houseNumber.trim();
try {
return Optional.of(Integer.parseInt(trimmed));
} catch (NumberFormatException e) {
return Optional.empty();
}
}
// 可选：业务层统一标准化（如将 "NO NUMBER" → "" 或 "N/A"）
public void normalizeHouseNumber() {
if ("NO NUMBER".equalsIgnoreCase(houseNumber)) {
this.houseNumber = "";
}
}
} 此时无需任何自定义反序列化器，Jackson 默认即可完成解析，后续逻辑按需调用 getHouseNumberAsInt() 或 normalizeHouseNumber()，灵活性与可维护性显著提升。
? 总结
| 方案 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| 自定义 JsonDeserializer | 快速修复遗留接口、强类型约束不可变 | 零侵入修改现有模型，立即生效 | 违背“门牌号非纯数字”的业务本质，长期维护成本高 |
| 改用 String + 业务方法 | 新项目或可重构场景 | 符合真实业务语义，扩展性强，无运行时异常风险 | 需调整下游使用逻辑（但通常只需少量适配） |
最终建议：优先采用方案二——以正确的数据类型承载业务含义，将“转换逻辑”下沉至领域方法而非序列化层。这不仅解决当前问题，更为国际化地址格式（如日本、阿联酋等复杂编号体系）预留了演进空间。
