AngstEssenSeele1. 问题场景还原：当Integer遇上"12.5kg"
上周三凌晨1点，我正在处理一个电商平台的库存同步接口。根据文档约定，商品重量字段应该是Integer类型（单位：克）。但当测试环境首次返回"12.5kg"这个字符串时，系统直接抛出了ClassCastException。更棘手的是，这个字段在业务逻辑中参与运费计算，错误直接导致整个订单流程中断。
这种情况在第三方对接中非常典型——文档声明是A，实际返回却是B。我立即用Postman抓包确认，发现响应体中确实存在三种数据形态：
- 理想情况："weight": 12500（纯数字）
- 常见异常："weight": "12500"（数字字符串）
- 本次极端案例："weight": "12.5kg"（含单位字符串）
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 类型安全防护的四层防御体系
2.1 第一层：契约校验（前置防护）
在Java中，推荐使用Bean Validation注解强化DTO定义：
java复制@NotNull
@Positive
private Integer weight;
但这对"12.5kg"这类复杂字符串无效，需要结合自定义校验器：
java复制@Constraint(validatedBy = WeightValidator.class)
public @interface ValidWeight {
// 校验逻辑实现
}
2.2 第二层：反序列化防护（核心防线）
以Jackson为例，可以自定义JsonDeserializer：
java复制public class WeightDeserializer extends JsonDeserializer<Integer> {
@Override
public Integer deserialize(JsonParser p, DeserializationContext ctxt) {
String raw = p.getText();
return parseWeight(raw); // 包含单位解析逻辑
}
}
在DTO字段上应用：
java复制@JsonDeserialize(using = WeightDeseriali