当 jackson 反序列化 json 时，默认按 javabean 规范将 `email` 推导为 `email`（首字母小写 + 驼峰拆分），导致字段名不匹配报错；本文介绍一种**无需 `@jsonproperty` 注解、不修改原始类、不引入额外依赖**的优雅绕过方案。
在使用 Jackson 进行 JSON 反序列化时，其默认的命名策略（PropertyNamingStrategies.LOWER_CAMEL_CASE）会将 Java 字段 eMail 映射为 JSON 键 "email"（即把 eMail 视为 e + Mail，首字母小写后拼接为 email）。这与实际 JSON 中的 "eMail" 字段名不一致，从而触发 UnrecognizedPropertyException。
虽然最直接的解法是为字段添加 @JsonProperty("eMail")，但问题明确要求不能修改原始类（如 PP），也不能引入 Jackson 注解依赖（目标是移除 fasterxml 依赖），因此需借助“中间层转换”思路实现零侵入适配。
✅ 推荐方案：中间 DTO + 手动转换
定义一个命名规范兼容的中间类（字段名严格对应 JSON），再通过简单方法转换为目标类型：
@Getter
@Setter
private static class IntermediatePP {
private String eMail; // 注意：此处字段名与 JSON 完全一致！
public PP convert() {
PP target = new PP();
target.setEMail(this.eMail);
return target;
}
}使用方式如下：
ObjectMapper mapper = new ObjectMapper();
String json = "{\"eMail\":\"test@example.com\"}";
PP result = mapper.readValue(json, IntermediatePP.class).convert();
System.out.println(result.getEMail()); // 输出: test@example.com⚠️ 关键细节：中间类字段名必须精确匹配 JSON 字段（即 eMail，而非 email），否则仍会失败。Jackson 默认策略对 eMail 的推导虽有歧义，但若字段名本身已与 JSON 一致，则无需任何配置即可直通反序列化。
? 补充说明：为什么不用 PropertyNamingStrategy？
你可能会想到配置 ObjectMapper 使用 PropertyNamingStrategies.IDENTITY（禁用自动重命名）：
mapper.setPropertyNamingStrategy(PropertyNamingStrategies.IDENTITY);
但该策略仅影响序列化输出字段名生成逻辑，对反序列化时的字段匹配行为无实质改善——因为 Jackson 在反序列化阶段仍依赖 AccessorNamingStrategy 和内部的 AnnotatedField 解析规则，而 eMail 的 getter/setter 方法名（如 getEMail()/setEMail()）仍会被解析为 email，导致匹配失败。实测该配置无法解决本例问题。
✅ 总结
- ✅ 零注解、零类修改、零依赖变更：完全满足约束条件；
- ✅ 精准可控、易于测试：转换逻辑集中、边界清晰；
- ✅ 可扩展性强：若后续出现其他非常规字段（如 XMLData, iOSVersion），可统一复用此模式；
- ❌ 不推荐反射/自定义 Deserializers 等高复杂度方案——违背“仅一个字段有问题”的轻量诉求。
该方案以最小代价达成最大兼容性，是处理遗留命名冲突场景下的务实之选。
