Jackson序列化时__type为null原因及解决方法

本文深入解析了 Jackson 序列化中 `__type` 字段为 `null` 的根本原因：当使用 `@JsonTypeInfo(include = EXISTING_PROPERTY)` 时，Jackson 并不会自动写入类型标识，而是严格依赖业务代码显式初始化该字段（如在子类构造器中调用 `setType("ConcreteRequest")`），否则序列化结果必然出现 `"__type": null`；文章不仅厘清了 `EXISTING_PROPERTY` 与 `PROPERTY`/`WRAPPER_OBJECT` 等模式的本质区别，还提供了可落地的修复方案、Builder 模式适配技巧、多子类一致性保障要点及替代策略权衡，帮助开发者真正理解这一“契约式多态”机制的设计意图，彻底规避因误解导致的序列化陷阱。

当使用 @JsonTypeInfo(include = EXISTING_PROPERTY) 时，Jackson 不会自动填充类型标识字段（如 __type），而是依赖该字段在运行时已显式赋值；若未手动设置，序列化结果中该字段即为 null。

当使用 `@JsonTypeInfo(include = EXISTING_PROPERTY)` 时，Jackson 不会自动填充类型标识字段（如 `__type`），而是依赖该字段在运行时已显式赋值；若未手动设置，序列化结果中该字段即为 `null`。

在基于 OpenAPI 生成的 Java 模型中，若采用 @JsonTypeInfo(include = JsonTypeInfo.As.EXISTING_PROPERTY, property = "__type") 实现多态序列化，开发者常误以为 Jackson 会在序列化时自动注入子类型名称（如 "ConcreteRequest"）到 __type 字段。但事实并非如此：EXISTING_PROPERTY 模式要求该字段必须由业务代码显式初始化并维护，Jackson 仅负责读取其当前值用于类型识别，不会自动写入。

核心机制说明

• include = EXISTING_PROPERTY 表示：序列化时将 __type 字段作为普通属性输出（值来自 getter），反序列化时则根据该字段值选择具体子类。
• 它与 include = WRAPPER_OBJECT 或 WRAPPER_ARRAY 的“自动包装”行为完全不同——后者由 Jackson 完全托管类型信息，而 EXISTING_PROPERTY 将控制权交还给开发者。

因此，若 ConcreteRequest 构造后未调用 setType("ConcreteRequest")，其继承自 BaseRequest 的 type 字段保持默认 null，最终导致 JSON 中 "__type": null。

正确实践：在子类构造器中显式设置类型标识

public class ConcreteRequest extends BaseRequest {
    public ConcreteRequest() {
        // ✅ 关键修复：显式设置 type 字段，确保序列化时非 null
        setType("ConcreteRequest");
    }

    // 其余字段和方法保持不变...
    private SoapTradeInput soapTradeInput;

    public ConcreteRequest soapTradeInput(SoapTradeInput soapTradeInput) {
        this.soapTradeInput = soapTradeInput;
        return this;
    }

    @JsonProperty("soapTradeInput")
    public SoapTradeInput getSoapTradeInput() {
        return soapTradeInput;
    }

    public void setSoapTradeInput(SoapTradeInput soapTradeInput) {
        this.soapTradeInput = soapTradeInput;
    }
}

? 提示：若存在多个子类（如 AnotherRequest, ThirdRequest），每个子类构造器均需设置对应 setType("...") 值，且该值必须与 @JsonSubTypes.Type(name = "...") 中声明的 name 完全一致（区分大小写）。

补充建议与注意事项

• 避免 setter 覆盖风险：若业务逻辑中可能多次调用 setType(...)，建议在构造器中设为 final 或添加校验（例如 Objects.requireNonNull(type, "type cannot be null") 在 getter 中）。

• 兼容 Builder 模式：若使用 Lombok @Builder 或自定义 Builder，需确保 type 字段被正确初始化：

  @Builder(builderMethodName = "concreteBuilder")
  public ConcreteRequest() {
      setType("ConcreteRequest");
  }

• 验证序列化结果：

  ObjectMapper mapper = new ObjectMapper();
  mapper.disable(SerializationFeature.WRITE_DATES_AS_TIMESTAMPS);
  // ... 其他配置保持不变
  
  ConcreteRequest req = new ConcreteRequest()
      .businessDate(LocalDate.of(2024, 1, 1))
      .soapTradeInput(new SoapTradeInput());
  
  String json = mapper.writeValueAsString(req);
  System.out.println(json);
  // ✅ 正确输出应包含： "__type":"ConcreteRequest"

• 替代方案考量：若希望完全免除手动维护 __type，可改用 include = JsonTypeInfo.As.PROPERTY（默认行为），此时 Jackson 会将类型信息作为独立属性注入（不复用业务字段），但需接受字段名与业务语义解耦。

总之，EXISTING_PROPERTY 是一种“契约式”多态策略——它赋予你对类型字段的完全控制权，但也要求你承担初始化责任。理解这一设计意图，是避免 __type: null 问题的根本前提。

好了，本文到此结束，带大家了解了《Jackson序列化时__type为null原因及解决方法》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多文章知识！