Jackson @JsonProperty注解详解：解决JSON字段映射，提升API开发效率

1. 项目概述从“属性名不匹配”的坑说起如果你写过Java后端接口尤其是和前端、移动端或者第三方系统做数据交互大概率踩过这样一个坑你定义了一个Java对象字段名叫userName结果前端传过来的JSON里键名是user_name或者你返回给前端的对象里有个字段叫createTime前端同学抱怨说收到的JSON里这个字段是create_time。这种命名风格不一致Java的驼峰命名 vs. JSON的蛇形命名导致的数据映射失败是日常开发中最常见的“低级”错误之一往往需要反复沟通、修改代码既低效又容易出问题。JsonProperty这个注解就是Jackson库Spring Boot默认的JSON处理器为我们提供的解决这类“名不对版”问题的瑞士军刀。它远不止于简单的字段名映射更是我们控制序列化Java对象转JSON与反序列化JSON转Java对象行为的核心工具。理解并熟练运用它能让你在构建清晰、健壮的API时更加得心应手避免大量不必要的胶水代码和沟通成本。这篇文章我就结合自己多年在Spring Boot项目中的实战经验为你彻底拆解JsonProperty的方方面面从基础用法到高阶技巧再到那些容易踩的坑让你一次搞懂从此告别JSON字段映射的烦恼。2. JsonProperty注解的核心能力与设计逻辑2.1 注解的定位与基本语法JsonProperty注解来源于com.fasterxml.jackson.annotation包它是Jackson数据绑定库的一部分。它的核心作用是指定一个Java属性在JSON表示中的属性名property name。这意味着当Jackson进行序列化或反序列化时将使用注解指定的名称而非Java属性本身的名称。其基本语法非常简单JsonProperty(json_field_name) private String javaFieldName;例如public class User { JsonProperty(user_name) private String userName; JsonProperty(created_at) private LocalDateTime createTime; }在这个例子中尽管Java类的字段是userName和createTime但在序列化成JSON时字段名会变成user_name和created_at同样反序列化时JSON中的user_name和created_at也会被正确地映射到Java对象的对应字段上。注意JsonProperty的值是大小写敏感的。“user_name”和“USER_NAME”会被视为两个不同的JSON属性。2.2 序列化与反序列化的双向控制这是JsonProperty最基础也是最重要的功能双向别名映射。它同时作用于序列化和反序列化两个过程。但Jackson的设计非常灵活它允许我们对这两个过程进行更精细的控制。JsonProperty注解本身有一个access属性可以用来指定该字段的访问权限。public class Product { // 该字段仅在序列化写入JSON时使用别名“id”反序列化时忽略 JsonProperty(value “id”, access JsonProperty.Access.WRITE_ONLY) private Long productId; // 该字段仅在反序列化从JSON读取时使用别名“name”序列化时使用原名“productName” JsonProperty(value “name”, access JsonProperty.Access.READ_ONLY) private String productName; }Access.WRITE_ONLY: 仅可写。意味着该字段只用于反序列化从JSON到Java对象。一个典型场景是接收前端传来的密码字段你希望这个字段能被解析到Java对象中用于业务逻辑如加密、验证但绝不希望它在返回给前端的JSON中出现。Access.READ_ONLY: 仅可读。意味着该字段只用于序列化从Java对象到JSON。常见于一些由后端计算生成的字段如订单总价、用户等级等这些字段不需要前端传入但需要返回给前端展示。Access.READ_WRITE: 可读可写默认值。即双向均使用指定的别名。实操心得明确区分READ_ONLY和WRITE_ONLY能极大提升API的安全性。对于像userId数据库自增ID、createTime服务器生成时间这类字段严格设置为READ_ONLY可以防止恶意用户通过API非法修改这些核心数据。2.3 处理缺失或空值的默认行为在实际的API交互中JSON数据可能缺失某些字段或者字段的值为null。JsonProperty可以与JsonInclude等注解配合但自身也通过defaultValue和required属性提供了一些控制能力。required属性标记该属性在反序列化时是否是必须的。如果设置为true当JSON中缺少此属性时Jackson会抛出JsonMappingException。JsonProperty(value “username”, required true) private String userName;这为API的输入验证提供了一层简单的保障。但请注意它只检查键是否存在不检查值是否为null或空字符串。defaultValue属性为属性指定一个默认值。当JSON中对应的属性缺失或值为null时会使用这个默认值来填充Java字段。但这里有一个非常重要的细节defaultValue主要影响的是反序列化行为并且它提供的是字符串形式的默认值Jackson会尝试将这个字符串转换为字段的实际类型如Integer、Boolean等。JsonProperty(value “age”, defaultValue “18”) private Integer age; // 如果JSON中没有“age”或其为nullage字段会被设置为18 JsonProperty(value “is_vip”, defaultValue “false”) private Boolean isVip;常见问题很多人误以为defaultValue也会影响序列化。实际上序列化时如果字段值是默认值如int的0boolean的false对象的null它仍然会被输出到JSON中除非你额外使用JsonInclude(JsonInclude.Include.NON_DEFAULT)来排除默认值。defaultValue的核心作用是给反序列化一个“保底”值避免因为数据缺失导致后续的NPE空指针异常或业务逻辑错误。3. 深入场景JsonProperty的实战应用与配置3.1 解决命名风格差异驼峰与蛇形命名转换这是JsonProperty最经典的应用场景。通常Java社区推崇驼峰命名法camelCase而许多其他系统如数据库表、Python后端、某些前端框架可能使用蛇形命名法snake_case。手动为每个字段添加JsonProperty虽然可行但很繁琐。更优雅的解决方案是配置Jackson的PropertyNamingStrategy。在Spring Boot中你可以在application.yml或application.properties中进行全局配置spring: jackson: property-naming-strategy: SNAKE_CASE或者在配置类中自定义Configuration public class JacksonConfig { Bean public Jackson2ObjectMapperBuilderCustomizer jacksonCustomizer() { return builder - builder.propertyNamingStrategy(PropertyNamingStrategies.SNAKE_CASE); } }配置之后整个应用的所有序列化和反序列化操作都会自动进行驼峰到蛇形的转换。此时JsonProperty的角色就变了它变成了一个覆盖全局命名策略的例外声明。例如有一个字段你不想遵循蛇形命名或者需要特殊的名字就可以用它来指定。public class ApiResponse { // 全局策略下这个字段在JSON中默认会是“error_code” private String errorCode; // 使用JsonProperty覆盖全局策略JSON中固定为“msg” JsonProperty(“msg”) private String message; // 另一个字段JSON中固定为“dataList”不转为蛇形 JsonProperty(“dataList”) private ListData dataList; }注意事项全局命名策略和JsonProperty注解的优先级需要明确。JsonProperty的指定具有最高优先级它会直接覆盖任何全局或类级别的命名策略。这种设计提供了灵活性大部分字段遵循惯例少数特殊字段可以特事特办。3.2 构建版本化或差异化的API响应随着业务发展同一个API可能需要为不同的客户端如App V1.0、App V2.0、Web端返回结构或字段名略有不同的JSON。一种粗暴的做法是创建多个DTOData Transfer Object类但这会导致代码冗余。利用JsonProperty和Jackson的视图View功能可以更优雅地解决。首先定义视图类public class Views { public static class Public {} // 公共视图 public static class Internal extends Public {} // 内部视图包含公共视图所有字段 public static class V1 extends Public {} // 版本1视图 public static class V2 extends Public {} // 版本2视图 }然后在DTO类中使用JsonProperty并结合JsonView来为不同视图指定不同的JSON字段名public class UserDTO { JsonView(Views.Public.class) JsonProperty(“id”) // 对所有公共视图字段名都是“id” private Long userId; JsonView(Views.Public.class) private String name; JsonView(Views.Internal.class) JsonProperty(“email_address”) // 仅在内部视图中邮箱字段使用蛇形命名 private String email; JsonView(Views.V1.class) JsonProperty(“reg_date”) // 针对V1版本API注册时间字段用“reg_date” private LocalDateTime registerTime; JsonView(Views.V2.class) JsonProperty(“registration_time”) // 针对V2版本API同一个字段用“registration_time” private LocalDateTime registerTime; // 注意同一个Java字段通过JsonView区分 }最后在Controller的方法上指定要使用的视图GetMapping(“/user/v1”) JsonView(Views.V1.class) public UserDTO getUserV1() { ... } GetMapping(“/user/v2”) JsonView(Views.V2.class) public UserDTO getUserV2() { ... } GetMapping(“/user/internal”) JsonView(Views.Internal.class) public UserDTO getUserInternal() { ... }这样通过同一个UserDTO类我们就实现了针对不同API端点返回不同字段名的JSON响应。这种方法的核心在于理解JsonView控制了哪些字段应该被序列化而JsonProperty则控制了这些被序列化的字段最终叫什么名字。两者结合实现了字段名和字段可见性的双重动态控制。3.3 与Lombok、MapStruct等工具链的协作在现代Java项目中Lombok用于自动生成getter/setter和MapStruct用于对象映射几乎是标配。它们与JsonProperty的协作有时会遇到一些小问题。与Lombok协作 Lombok会在编译时生成getter和setter方法。Jackson默认通过getter/setter来访问属性如果存在的话而不是直接访问字段。因此当你对字段使用JsonProperty时需要确保Lombok生成的getter/setter方法名符合Jackson的推断规则或者显式地在getter/setter上也加上注解。import lombok.Data; import com.fasterxml.jackson.annotation.JsonProperty; Data public class UserWithLombok { // 将注解放在字段上通常可以正常工作。 // Jackson会先查找字段上的注解再查找getter/setter上的注解。 JsonProperty(“user_name”) private String userName; // 更稳妥的做法如果遇到问题可以在getter或setter上也添加注解 JsonProperty(“email”) public String getEmail() { return this.email; } JsonProperty(“email”) public void setEmail(String email) { this.email email; } private String email; }一个常见的坑是如果你使用了Lombok的Getter和Setter并且自定义了访问器级别如Getter(AccessLevel.PROTECTED)可能会导致Jackson找不到合适的getter/setter从而序列化/反序列化失败。此时检查编译后的class文件确认方法是否存在以及JsonProperty注解是否被保留在相应的方法上是有效的排查手段。与MapStruct协作 MapStruct用于在两个Java对象之间进行属性拷贝。它通常不直接处理JSON而是处理Java对象。因此JsonProperty注解本身对MapStruct的映射过程没有影响。MapStruct只关心源对象和目标对象的属性名是否匹配。// 源DTO用于接收API请求 public class UserRequestDTO { JsonProperty(“user_name”) // JSON中的字段名 private String userName; // getter/setter } // 目标实体用于持久化 public class UserEntity { private String userName; // 数据库字段名通常是驼峰 // getter/setter } // MapStruct Mapper接口 Mapper public interface UserMapper { UserMapper INSTANCE Mappers.getMapper(UserMapper.class); // MapStruct会根据名称“userName”进行映射与JsonProperty无关 UserEntity toEntity(UserRequestDTO dto); }在这个例子中尽管UserRequestDTO的字段有JsonProperty(“user_name”)但它的Java字段名仍然是userName。MapStruct在映射时会成功地将UserRequestDTO.userName的值拷贝到UserEntity.userName。JsonProperty只在Jackson处理JSON与UserRequestDTO转换时起作用。这种解耦是非常清晰的。4. 高级技巧与性能考量4.1 在抽象类、父类及接口上的应用JsonProperty注解是可以被继承的。这意味着如果你在父类或抽象类的字段或方法上使用了该注解那么子类在序列化/反序列化时也会继承这一行为。public abstract class BaseEntity { JsonProperty(“id”) private Long id; // 所有子类的id字段在JSON中都会显示为“id” JsonProperty(“created_at”) private LocalDateTime createdAt; // ... getters and setters } public class User extends BaseEntity { private String name; // 序列化User对象时JSON会包含从BaseEntity继承来的“id”和“created_at”字段 }这个特性对于定义公共的API响应结构非常有用。你可以创建一个基础的ApiResponse类包含code、message、timestamp等通用字段并统一用JsonProperty定义好它们的JSON名称。所有具体的响应DTO都继承这个基类从而保证所有API返回的通用字段命名一致。注意事项如果子类想覆盖父类的JsonProperty定义可以直接在子类的同名字段上重新声明该注解。子类的注解优先级高于父类。4.2 处理多态类型Polymorphic Type Handling与注解继承在使用Jackson的多态类型处理通过JsonTypeInfo和JsonSubTypes时JsonProperty的行为依然符合继承规则。考虑一个动物类的例子JsonTypeInfo(use JsonTypeInfo.Id.NAME, property “type”) JsonSubTypes({ JsonSubTypes.Type(value Dog.class, name “dog”), JsonSubTypes.Type(value Cat.class, name “cat”) }) public abstract class Animal { JsonProperty(“animal_name”) private String name; } public class Dog extends Animal { JsonProperty(“bark_volume”) private int barkVolume; } public class Cat extends Animal { JsonProperty(“claw_sharpness”) private int clawSharpness; }当你序列化一个Dog对象时产生的JSON会包含从Animal继承来的animal_name字段以及自身定义的bark_volume字段同时还会包含多态类型标识符type: “dog”。这展示了JsonProperty在复杂的对象继承体系中的稳定作用。4.3 配置的优先级与性能影响理解Jackson中各种配置的优先级对于调试和设计API至关重要。以下是影响字段名映射的配置按优先级从高到低排列字段/方法上的JsonProperty注解优先级最高直接指定最终名称。类上的JsonPropertyOrder或JsonNamingJsonNaming可以给整个类指定一个命名策略如JsonNaming(PropertyNamingStrategies.SnakeCaseStrategy.class)它会作用于类中没有被JsonProperty显式注解的所有属性。ObjectMapper 或 Spring Boot 的全局命名策略如PropertyNamingStrategies.SNAKE_CASE优先级最低作为默认策略应用。关于性能JsonProperty注解本身是在Jackson初始化ObjectMapper并构建属性元数据时被解析的这个过程通常发生在应用启动阶段或第一次处理某个类时。一旦元数据构建完成在后续的序列化/反序列化操作中使用注解与直接使用字段名相比几乎没有额外的运行时性能开销。因为Jackson内部使用的是缓存好的元数据信息而不是每次操作都去反射读取注解。因此可以放心地在项目中使用JsonProperty来提升代码的清晰度和健壮性无需担心性能问题。5. 常见问题排查与实战避坑指南在实际开发中仅仅知道如何使用JsonProperty还不够更重要的是知道当它“不工作”时如何排查。下面是一些高频问题和我的排查思路。5.1 注解不生效的典型场景与排查步骤当你发现JsonProperty注解没有按预期改变JSON字段名时可以按照以下步骤排查检查注解导入包确保导入的是com.fasterxml.jackson.annotation.JsonProperty而不是其他包下同名的注解虽然这种情况较少见但在一些老项目或依赖混乱时可能发生。检查Getter/Setter方法如果类中存在公共的getter和setter方法Jackson默认会通过它们来访问属性。此时注解在方法上的优先级高于字段。检查是否在getter/setter上存在冲突的JsonProperty注解或者是否因为Lombok等工具生成了方法导致字段上的注解被忽略。一个快速验证的方法是尝试将JsonProperty注解移到getter方法上。检查ObjectMapper配置你是否自定义了ObjectMapper并关闭了注解功能检查配置中是否有mapper.disable(MapperFeature.USE_ANNOTATIONS)这样的语句。在Spring Boot中如果你通过Jackson2ObjectMapperBuilderCustomizer或Bean方式创建了自定义的ObjectMapper需要确保没有禁用注解支持。检查属性可见性Jackson需要能访问到属性字段或方法。如果字段是private但没有getter/setter且没有通过JsonAutoDetect放宽可见性规则Jackson可能无法发现该字段注解自然无效。确保字段有合适的访问器或配置了JsonAutoDetect(fieldVisibility Visibility.ANY)。使用调试工具在测试用例中使用ObjectMapper的writeValueAsString()和readValue()方法进行序列化和反序列化测试并打印结果。这是最直接的验证方式。5.2 与JsonIgnore、JsonFormat等注解的冲突与优先级当多个Jackson注解作用于同一个属性时需要理解它们的优先级和潜在冲突。JsonPropertyvsJsonIgnoreJsonIgnore的优先级更高。如果一个字段同时被JsonProperty和JsonIgnore标记该字段会被完全忽略既不会序列化也不会反序列化。JsonIgnore通常用于彻底隐藏一个字段。JsonPropertyvsJsonFormat这两个注解处理的是不同维度的问题没有冲突。JsonProperty控制字段名JsonFormat控制字段值通常是日期、数字的格式。JsonProperty(“birthday”) JsonFormat(pattern “yyyy-MM-dd”) private LocalDate birthDate; // 序列化结果 “birthday”: “1990-01-01”JsonProperty与required属性前面提到required true会在反序列化时检查JSON中是否存在该键。但如果该字段同时被JsonIgnore忽略或者其getter被标记为JsonIgnore那么required属性将不起作用因为该字段根本不会参与反序列化过程。5.3 在Spring Boot Web环境下的特殊行为在Spring Boot的Web MVC环境中Controller方法的参数绑定和返回值处理通常由MappingJackson2HttpMessageConverter完成它背后使用的就是配置好的ObjectMapper。大部分情况下JsonProperty的行为与直接使用ObjectMapper一致。但需要注意以下几点RequestBody与ResponseBody这两个注解的处理完全依赖于配置的ObjectMapperJsonProperty注解会正常生效。RequestParam和PathVariable这两个注解用于绑定URL参数和路径变量其处理过程不经过Jackson的ObjectMapper因此JsonProperty注解对它们无效。它们绑定的是参数名本身。ModelAttribute用于绑定表单数据application/x-www-form-urlencoded或multipart/form-data。这个绑定过程是由Spring的DataBinder完成的而不是Jackson。因此JsonProperty注解同样无效。表单字段名需要与Java对象的属性名或setter方法名匹配。全局配置覆盖如果你在Spring Boot配置文件中设置了spring.jackson.property-naming-strategy: SNAKE_CASE那么所有通过Jackson处理的地方都会生效包括RequestBody、ResponseBody以及任何你手动注入使用的ObjectMapperBean。一个真实的踩坑案例我们曾有一个API接收一个复杂的查询条件对象最初用RequestBody接收JSON工作正常。后来为了便于前端调试改为用ModelAttribute接收URL查询参数结果所有蛇形命名的字段都绑定不上了因为JsonProperty在ModelAttribute绑定中无效。解决方案要么是修改前端传参为驼峰格式要么在Java对象上使用RequestParam一个个手动绑定要么就保持使用RequestBody。这个案例提醒我们选择参数绑定注解时需要清楚其背后的处理机制。5.4 序列化循环引用与JsonProperty的间接影响JsonProperty本身不会导致循环引用但在处理具有双向关联的对象时如Order和OrderItemOrder中有ListOrderItemOrderItem中又有Order属性循环引用是一个常见问题。Jackson在序列化时会陷入无限循环直到栈溢出。标准的解决方案是使用JsonManagedReference和JsonBackReference或者JsonIgnore来切断循环。这里JsonProperty可能会带来一个间接问题如果你在切断循环的字段上错误地使用了JsonProperty可能会干扰引用注解的工作。public class Order { JsonManagedReference // 序列化时这部分会被正常展开 JsonProperty(“items”) // 指定JSON字段名 private ListOrderItem items; } public class OrderItem { JsonBackReference // 序列化时这个属性会被忽略避免循环 // 注意这里不要再加 JsonProperty因为该字段已被忽略注解无效且可能引起混淆 private Order order; }最佳实践是在处理循环引用的字段上优先使用JsonManagedReference/JsonBackReference或JsonIgnore确保循环被正确切断后再考虑是否需要在另一侧被展开的一侧使用JsonProperty来定制字段名。避免在JsonBackReference或JsonIgnore标注的字段上添加JsonProperty这没有意义且可能让代码读者困惑。6. 超越JsonProperty相关注解与组合使用虽然JsonProperty功能强大但Jackson注解生态中还有其他与之相关的利器组合使用能解决更复杂的问题。6.1 JsonAlias处理多个可能的JSON字段名JsonAlias是JsonProperty一个非常有用的补充。它只在反序列化时生效为一个Java属性定义一组别名。当JSON中出现这些别名中的任何一个时都能被正确地反序列化到该属性上。这在处理不同版本或不同来源的API时特别有用。public class Product { // 反序列化时JSON中的“id”、“product_id”、“pid”都会被映射到productId字段 JsonAlias({“product_id”, “pid”}) JsonProperty(“id”) // 序列化时固定使用“id” private Long productId; }注意JsonAlias只影响反序列化不影响序列化。序列化时使用的名称仍然由JsonProperty如果存在或默认的命名策略决定。这种设计实现了“反序列化时兼容多种输入序列化时输出统一格式”的需求。6.2 JsonGetter与JsonSetter在方法级别定义JSON属性有时JSON属性并非直接对应一个字段而是通过某个getter方法计算得出或者需要通过一个setter方法进行复杂的设置。此时可以在方法上使用JsonGetter和JsonSetter它们的作用类似于在方法上使用JsonProperty。public class Account { private String firstName; private String lastName; // 序列化时会生成一个名为“full_name”的JSON属性其值为该方法返回值 JsonGetter(“full_name”) public String getFullName() { return firstName “ “ lastName; } // 反序列化时接收“full_name”这个JSON属性并将其值拆分设置到firstName和lastName字段 JsonSetter(“full_name”) public void setFullName(String fullName) { String[] parts fullName.split(“ “, 2); this.firstName parts[0]; this.lastName parts.length 1 ? parts[1] : “”; } }这种方法提供了极大的灵活性允许你将任何计算逻辑封装成JSON属性。需要注意的是如果字段上也有JsonProperty且方法名遵循JavaBean规范如getFullNameJackson可能会产生混淆。通常建议对于计算属性只在方法上使用JsonGetter/JsonSetter对于直接映射的字段属性使用字段上的JsonProperty。6.3 使用JsonNaming进行类级别的全局命名策略如果你觉得在每个字段上写JsonProperty太麻烦且整个类的命名风格需要统一转换JsonNaming是更好的选择。它可以标注在类上为这个类的所有属性指定一个命名策略。JsonNaming(PropertyNamingStrategies.SnakeCaseStrategy.class) public class ApiRequest { private String userName; // 序列化为 user_name private String emailAddress; // 序列化为 email_address private LocalDateTime createTime; // 序列化为 create_time // 无需为每个字段添加JsonProperty(“snake_case”) }PropertyNamingStrategies提供了多种内置策略如SNAKE_CASE蛇形、UPPER_CAMEL_CASE帕斯卡、LOWER_CAMEL_CASE驼峰默认、KEBAB_CASE烤肉串如user-name等。你甚至可以自定义实现PropertyNamingStrategy接口来满足特殊需求。组合使用建议通常我会在项目的配置类中设置一个全局的蛇形命名策略。然后在具体的DTO类上如果绝大部分字段都遵循这个策略就不做处理。对于少数需要特殊命名的字段再使用JsonProperty进行覆盖。对于需要兼容多个JSON字段名进行反序列化的属性使用JsonAlias。对于计算属性使用JsonGetter/JsonSetter。这套组合拳能应对绝大多数复杂的JSON映射场景。7. 自定义序列化/反序列化与JsonProperty的协作对于极端复杂的场景你可能需要完全控制某个字段的序列化或反序列化过程这时就需要用到自定义的JsonSerializer和JsonDeserializer。即使在这种情况下JsonProperty依然扮演着重要的角色。7.1 在自定义序列化器中保留字段名信息当你为某个字段指定了自定义序列化器时JsonProperty注解定义的属性名仍然是有效的。Jackson会先确定字段的JSON属性名根据JsonProperty或命名策略然后再用你自定义的序列化器来处理这个属性的值。public class CustomObject { JsonProperty(“encrypted_data”) JsonSerialize(using EncryptSerializer.class) // 使用自定义序列化器 private String sensitiveData; JsonProperty(“formatted_date”) JsonSerialize(using CustomDateSerializer.class) private LocalDateTime date; }在上面的例子中序列化后的JSON键名仍然是encrypted_data和formatted_date只是它们的值分别由EncryptSerializer和CustomDateSerializer来生成。JsonProperty确保了字段名的正确性而自定义序列化器则专注于值的转换逻辑。7.2 在自定义反序列化器中映射字段名同理在自定义反序列化器中你通常需要从JsonParser中读取数据。虽然反序列化器主要关心如何将JSON值转换成Java对象但字段名的识别仍然由Jackson框架基于JsonProperty或JsonAlias来完成。反序列化器被调用时它已经知道当前要处理的是哪个字段通过JsonParser的上下文信息。你不需要在反序列化器代码里硬编码字段名。public class CustomObject { JsonProperty(“special_field”) JsonDeserialize(using ComplexDeserializer.class) private ComplexType field; }在ComplexDeserializer的deserialize方法中你可以直接使用parser.getCurrentName()来获取当前正在处理的JSON字段名这个名称已经是经过JsonProperty映射后的逻辑名然后根据这个名称为ComplexType对象设置相应的值。核心要点JsonProperty以及相关的命名策略注解负责“映射哪个JSON键到哪个Java属性”这一层逻辑。而自定义的反序列化器负责“如何转换这个键对应的值”这一层逻辑。两者是正交的可以很好地协作。这种分离关注点的设计使得Jackson非常灵活和强大。