JSON序列化与反序列化中的多态处理：原理、方案与安全指南

我先把话说在前面：JSON的序列化和反序列化，看起来是个谁都会用的基础功能，但一旦涉及“多态”，水就深了。很多项目做到后期，遇到的最隐蔽、最难排查的那类问题——字段丢失、类型不对、ClassCastException、甚至反序列化漏洞，根源常常就藏在这两个字里。这篇文章我就围绕“JSON序列化与反序列化中的多态处理”这个主题，把原理、方案、坑点、安全边界一次性讲透。不管你是写Java、Python、C++，还是做架构设计，只要你的系统里有继承和多态，这篇文章都值得你花十分钟读完，并在下次写DTO时想起它。

1. 多态信息是怎么在JSON链路里丢掉的

1.1 一次线上消费端“字段凭空消失”的故障

先说个我实际经历过的故障。

当时我们有个订单事件总线，上游服务把一个 OrderCreatedEvent 对象序列化成JSON扔到消息队列。这个 OrderCreatedEvent 继承自一个 BaseOrderEvent，里面除了公共字段 orderId、timestamp 之外，还有一个子类特有的字段 discountAmount。下游消费服务拿到消息后，反序列化成 BaseOrderEvent 去处理，结果 discountAmount 这个字段直接就是 null。

最诡异的是，JSON文本里明明有 discountAmount 这个字段，序列化那一端没有丢，可消费端反序列化之后它就是拿不到。

这其实是一个非常典型的多态序列化问题。上游序列化时，对象的动态类型是 OrderCreatedEvent，Jackson会把它的字段都写进JSON（包括继承来的和子类自己新增的）。但下游反序列化时，声明的目标类型是 BaseOrderEvent，Jackson只能依据这个静态类型去创建对象。你想想，BaseOrderEvent 这个类根本没有 discountAmount 属性，Jackson拿到那个字段后，默认策略是直接忽略掉，结果就是：数据明明就在JSON里，但你读出来是空的。

这个问题用下面这段代码就能复现：

java复制public class BaseOrderEvent {
    public String orderId;
    public long timestamp;
}

public class OrderCreatedEvent extends BaseOrderEvent {
    public BigDecimal discountAmount;
}

// 序列化
OrderCreatedEvent event = new OrderCreatedEvent();
event.orderId = "A001";
event.timestamp = System.currentTimeMillis();
event.discountAmount = new BigDecimal("19.90");

String json = objectMapper.writeValueAsString(event);
System.out.println(json);
// 输出：{"orderId":"A001","timestamp":1720000000000,"discountAmount":19.90}

// 反序列化
BaseOrderEvent parsed = objectMapper.readValue(json, BaseOrderEvent.class);
System.out.println(parsed.discountAmount);
// 输出：null，而且编译不过，因为BaseOrderEvent根本没有这个字段

这段代码的核心矛盾在于：JSON只能描述“对象长什么样”，描述不了“这个对象是什么类型”。除非你显式地把类型信息也写进JSON里，否则反序列化端只能靠猜。

1.2 JSON的数据模型本身没有“类型系统”

JSON格式本身只定义了六种值类型：string、number、object、array、boolean、null。它没有一个叫“类”或“类型标签”的概念。换句话说，JSON里的每一个对象天然不知道自己是某个类的实例。

做序列化的库（Jackson、Gson、fastjson）之所以能把一个Java对象变成JSON，靠的是反射去遍历对象的属性和结构。但反序列化就麻烦了：当你给它一段JSON和你的目标类型时，它只能按照你给的目标类型去实例化对象，挨个字段匹配赋值。

这就好比你把一堆零件（字段）装进了一个没有任何标签的箱子里，运输过程中箱子是完整的，但收货方不知道这箱零件原本该组装成“椅子”还是“桌子”，他只能按照自己手里图纸上的型号去组装。如果图纸上写的是“桌子”，那箱子里属于“椅子”的配件自然就被当成多余零件扔掉了。

问题来了：Java、C++、Python、PHP这类面向对象语言里，多态恰恰意味着一个变量在编译期是父类型，在运行期却可能是任意一个子类型。父类型的“图纸”根本不包含子类型自定义的字段。所以，多态和JSON天然是不兼容的，你需要用某种约定去弥补这个缺口。

1.3 先确认你的业务是不是真的需要多态

在给方案之前，我想先说一句可能会得罪人的话：不是所有“多个子类继承父类”的场景都适合直接做多态JSON序列化。

我在项目里见过不少把多态JSON用得很别扭的案例。比如一个接口返回的DTO里定义了一个父类字段，然后实际塞进去的是某个子类，但下游消费方根本不需要关心子类是什么，所有端都只按父类字段处理。这种情况下，你完全可以把子类拍平成一个普通DTO，或者用组合代替继承，没必要为了“设计模式”而引入多态序列化的复杂度。

真正需要多态JSON的场景，通常有这几个特征：

如果你的业务不属于上面这些模式中的任何一种，那我建议你还是别用多态序列化，老老实实拆分字段，省下来的可能是一整年的排查时间。

2. Jackson多态反序列化的标准解法：JsonTypeInfo

2.1 三个注解的配合逻辑

Java里用Jackson处理多态序列化，核心就是 @JsonTypeInfo 这个注解。它的作用就是序列化时在JSON里写入一个“类型标识字段”，反序列化时根据这个标识去实例化对应的子类。

我自己最常用的组合是：

java复制@JsonTypeInfo(
        use = JsonTypeInfo.Id.NAME,
        include = JsonTypeInfo.As.PROPERTY,
        property = "type",
        visible = true,
        defaultImpl = BaseOrderEvent.class
)
@JsonSubTypes({
        @JsonSubTypes.Type(value = OrderCreatedEvent.class, name = "ORDER_CREATED"),
        @JsonSubTypes.Type(value = OrderCancelledEvent.class, name = "ORDER_CANCELLED")
})
public class BaseOrderEvent {
    public String orderId;
    public long timestamp;
}

然后子类上可以再加一个 @JsonTypeName 来指定类型名，也可以不加、直接用 @JsonSubTypes.Type 里的名字：

java复制@JsonTypeName("ORDER_CREATED")
public class OrderCreatedEvent extends BaseOrderEvent {
    public BigDecimal discountAmount;
}

序列化出来的JSON大概长这样：

json复制{
  "type": "ORDER_CREATED",
  "orderId": "A001",
  "timestamp": 1720000000000,
  "discountAmount": 19.90
}

注意 type 字段被显式放在了最前面（实际Jackson是按字段顺序插进去的，有时候不一定在最前，但效果一样）。反序列化时，Jackson看到 type 的值是 ORDER_CREATED，就会自动去匹配 @JsonSubTypes 里注册的子类，然后创建 OrderCreatedEvent 对象。

有几个参数组合很容易把人绕晕，我根据自己的实战经验简单说下：

• use = JsonTypeInfo.Id.NAME 是最推荐的，它用你在 @JsonSubTypes 或 @JsonTypeName 中指定的简短别名做类型标识，可读性好，将来类型重命名也不影响存储的JSON。
• use = JsonTypeInfo.Id.CLASS 是把类的全限定名写进去，比如 "type": "com.example.OrderCreatedEvent"。这个方案不用维护映射表，但代价是暴露了类路径，一旦类重命名或包调整，历史数据就对不上了，而且有安全隐患（后面说）。
• include = JsonTypeInfo.As.PROPERTY 是最直观的，类型信息作为JSON对象里的一个普通属性。如果传的是XML或二进制类，还有 As.WRAPPER_OBJECT、As.WRAPPER_ARRAY 等模式，但咱们讲JSON，用 PROPERTY 就够了。
• visible = true 非常关键。它的意思是：反序列化时，这个 type 字段除了用来定位类型，还会保留到目标对象上。如果你不设置 visible = true，type 字段会被Jackson当成元数据消费掉，反序列化后的对象里拿不到这个字段。有时候业务上有需要，比如日志里要保留来源类型，就必须设为true。

2.2 defaultImpl参数：你不知道类型时的兜底方案

这里我必须重点强调 defaultImpl 的作用。

假设你的生产者已经升级，写入了新的事件类型 ORDER_REFUNDED，但消费者还没升级，@JsonSubTypes 里没有注册这个类型。如果没写 defaultImpl，Jackson反序列化时会直接抛异常：

code复制com.fasterxml.jackson.databind.exc.InvalidTypeIdException: 
Could not resolve type id 'ORDER_REFUNDED' as a subtype of BaseOrderEvent

在有消息队列的架构里，这往往意味着消费端一崩崩一批、消息积压、重试风暴。而且更麻烦的是，如果消费者代码里没有对这种情况做兜底，这个错误消息会反复进重试队列，把磁盘和日志都打满。

而设置了 defaultImpl = BaseOrderEvent.class 之后，遇到未知类型标识，Jackson会降级创建 BaseOrderEvent 对象，公共字段能解析多少是多少，子类特有字段丢失但不报错。这在升级顺序不一致的微服务架构里，是保命级的配置。

记住这个原则：**生产者的枚举值可以比消费者新，但不能让消费者因为未知类型而崩溃。**能用 defaultImpl 兜底就用，别依赖“我们约定好两端同步升级”这种话。

2.3 实战中踩过的几个坑

这个方案看着简单，实际落地时还是有不少坑的，我把最常见的几个列出来。

坑一：字段不可见导致的多态失效

Jackson默认只处理公共的getter/setter和public字段。如果你子类的属性是private，又没有getter/setter，那这个字段不会出现在序列化结果里。更隐蔽的是，如果你的父类没有无参构造函数，Jackson在反序列化时也会出问题。我的建议是：被序列化的多态模型保持简单的POJO风格，属性用public也行，只要团队规范允许；或者统一用Lombok的@Data让它自己生成getter/setter。

坑二：@JsonTypeName的全局唯一性

@JsonTypeName("ORDER_CREATED") 这个别名在同一个ObjectMapper上下文里全局唯一。如果你两个不同父类的子类用了同一个名字，反序列化时Jackson可能无法确定该映射到哪个类，或者直接报错。规范做法是在一个模块里统一定义类型名，最好用一个公共常量类或枚举来约束。

坑三：泛型子类的情况要单独处理

如果你的子类带泛型，比如 ResultEvent<T>，情况会稍微复杂。反序列化时Jackson拿到的类型标识只能定位到 ResultEvent，但 T 具体是什么类型，需要额外信息。比如你可以在 type 之外再加一个 className 保存泛型实参的类型名；或者更简单的做法是，把泛型实参的信息编码进 type 别名里，比如 "RESULT_ORDER"、"RESULT_USER" 分开。这里没有银弹，得根据业务场景取舍。

坑四：与@JsonCreator配合的冲突

如果你在多态模型里写了 @JsonCreator 的构造函数或工厂方法，并且参数里有 type 字段，要注意 visible = true 在这种场景下的表现。我遇到过一种情况：type 字段被传进了构造函数，然后又作为属性被设置了一遍，结果setter里做了校验逻辑，导致反序列化失败。解决方案通常是构造函数参数里排除 type 字段，或者调整 visible 参数。

3. 从注解到全局配置：再也不用每加一个子类就改代码

3.1 新增子类总是忘改JsonSubTypes，这个痛点怎么破

@JsonTypeInfo + @JsonSubTypes 的方案默认行为是：每新增一个子类，你都要记得去父类上把 @JsonSubTypes 改一遍。项目规模小的时候没什么感觉，但子类数量超过十个以后，几乎每周都会有人忘记注册，然后上线后某个分支的逻辑因为反序列化失败而报警。

解决思路有两个方向：一是通过代码生成或工具在编译期检查，二是用动态注册。

动态注册在Jackson里一般会用 ObjectMapper.registerSubtypes() 方式，把需要支持的子类集中注册到ObjectMapper配置里，而不是散落在各个注解中。这样你至少可以把注册代码集中在一个配置文件或配置类里，比到处加注解强，但本质还是没有避免“手动维护清单”这件事。

真正省事的做法是：**结合Spring的类路径扫描，把指定包下所有带特定标记的子类自动注册进去。**比如规定所有可反序列化子类都加一个 @TypeAlias("XXX") 注解，然后在配置类里扫描这个包，自动注册。这样新加一个子类，只要类文件在包里，不用改任何注册代码就能生效。

3.2 自定义TypeIdResolver的简化实现

Jackson提供了 TypeIdResolver 接口，允许你完全控制类型标识与类的双向映射。我做一个简化版的示例，思路是扫描包下的类，用 @TypeAlias 注解作为类型标识。

java复制public class AliasTypeIdResolver implements TypeIdResolver {

    private static final Map<String, Class<?>> idToClassMap = new HashMap<>();
    private static final Map<Class<?>, String> classToIdMap = new HashMap<>();

    public static void init(String scanPackage) {
        // 扫描指定包下所有使用@TypeAlias注解的类
        // 这里用Spring的ClassPathScanningCandidateComponentProvider或反射工具扫描
        // 伪代码示例：
        // for (Class<?> clazz : scanClasses(scanPackage)) {
        //     TypeAlias alias = clazz.getAnnotation(TypeAlias.class);
        //     idToClassMap.put(alias.value(), clazz);
        //     classToIdMap.put(clazz, alias.value());
        // }
    }

    @Override
    public String idFromValue(Object value) {
        return classToIdMap.get(value.getClass());
    }

    @Override
    public String idFromValueAndType(Object value, Class<?> suggestedType) {
        return idFromValue(value);
    }

    @Override
    public JavaType typeFromId(DatabindContext context, String id) throws IOException {
        Class<?> clazz = idToClassMap.get(id);
        if (clazz == null) {
            // 兜底处理：返回父类，而不是抛异常
            return context.getTypeFactory().constructType(BaseOrderEvent.class);
        }
        return context.getTypeFactory().constructType(clazz);
    }

    @Override
    public JsonTypeInfo.Id getMechanism() {
        return JsonTypeInfo.Id.CUSTOM;
    }
}

然后在父类上改成：

java复制@JsonTypeInfo(
        use = JsonTypeInfo.Id.CUSTOM,
        include = JsonTypeInfo.As.PROPERTY,
        property = "type",
        visible = true,
        defaultImpl = BaseOrderEvent.class
)
@JsonTypeIdResolver(AliasTypeIdResolver.class)
public class BaseOrderEvent {
    public String orderId;
    public long timestamp;
}

这个方案的本质是把“子类清单”从静态注解迁移到了类路径扫描。实际项目中我一般还会加缓存，避免每次序列化都去反射扫描。启动时扫描一次，运行时只走Map查找，性能完全不是问题。

3.3 一个更“重”的方案：全局Default Typing

如果你不是只想处理某一个父类，而是希望整个系统里所有对象都自动携带类型信息，那么可以用ObjectMapper的全局多态配置：

java复制ObjectMapper objectMapper = new ObjectMapper();
objectMapper.activateDefaultTyping(
        objectMapper.getPolymorphicTypeValidator(),
        DefaultTyping.NON_FINAL,
        JsonTypeInfo.As.PROPERTY
);

activateDefaultTyping 会让Jackson在序列化非final类时自动写入类型信息。这个方案确实省事，很多框架内部就是这么做的。但副作用也很明显：你的JSON会变得非常啰嗦，嵌套对象的类型信息层层包裹，可读性变差，而且跨系统对接时对方如果不理解这套格式，会被“带引号的数组”这种结构搞得一头雾水。

DefaultTyping 还涉及一个安全防线：PolymorphicTypeValidator。在Java 17加模块化限制和反序列化漏洞频出之后，官方强烈建议配置这个Validator来限制允许反序列化的类范围。没有它，你等于把系统敞开给了攻击面。

我的建议是：**全局Default Typing更适合框架内部通信，不适合对外接口。**对外接口和跨团队消息，还是用显式 @JsonTypeInfo 更可控，也更容易做兼容性治理。

4. 跨语言视角：多态序列化不是Java独有难题

4.1 PHP和Python的“带类型序列化”思路

对象序列化这个事，其实不止Java有。PHP的 serialize() 会直接把类名写进字符串里，比如 O:15:"OrderCreatedEvent":3:{...}；Python的 pickle 同样会携带类引用信息。这些方案在“反序列化回原类型”这件事上非常方便，甚至比Jackson的 @JsonTypeInfo 更直接——因为它们不需要你自己维护类型映射表。

但代价也很明显：**安全风险显著增加。**攻击者如果控制了你反序列化的内容，等于可以指定任意类被加载和实例化，配合某些类的 __wakeup()、__set_state()、__reduce() 等方法，就能造成任意代码执行——这就是PHP/Python反序列化漏洞的底层逻辑。热搜词里频繁出现“phar反序列化”“pickle反序列化”，本质都是同一个原理。

所以现在的主流建议是：跨语言、跨系统传递数据时，不要用语言原生的序列化格式，尽量用JSON、protobuf这类跨语言的中间格式。 用JSON你至少得显式写类型字段，可控性好；用 pickle 或 serialize()，等于把类型安全全押在了链路安全上，一旦有一环被攻破，后果不可控。

4.2 C++、C#和Go生态的“手动类型字段+工厂”

C++和Go的标准JSON库，理论上根本没有“多态序列化”的概念。C++的 nlohmann/json 只是把对象转换成 json 类型的Value，根本不知道什么继承；Go的 encoding/json 面对接口字段时，要么把值塞进map，要么用 json.RawMessage 延迟解析。

所以C++/Go项目里处理多态，最常见的模式就是“手动type字段 + 工厂函数”：

go复制type Event struct {
    Type string          `json:"type"`
    Data json.RawMessage `json:"data"`
}

// 先读Type，再根据Type把Data解析到具体结构体
var raw map[string]json.RawMessage
json.Unmarshal(data, &raw)
var eventType string
json.Unmarshal(raw["type"], &eventType)

switch eventType {
case "ORDER_CREATED":
    var e OrderCreatedEvent
    json.Unmarshal(raw["data"], &e)
    // ...
}

这种方案其实比Jackson的 @JsonTypeInfo 更“笨”，但反过来也意味着它更透明、更可控。Type字段放在外层，Data字段单独打包，有利于保持事件结构的稳定。

到了C#那边，System.Text.Json 从 .NET 7开始加入了多态序列化支持，用 [JsonDerivedType(typeof(DerivedType), "typeName")] 特性，思路和Jackson基本一致，也是往JSON里写一个类型字段。这说明大家最终都殊途同归：类型信息必须显式进入数据格式，否则多态无从谈起。

4.3 各语言方案对比与选型建议

做跨语言架构时，我个人的建议是：不要让每个服务都用自家语言原生的多态能力，而是统一定义一种“信封”格式——外层带着类型标识和元数据，内层放业务数据。这样Java服务加字段不影响Python服务，只要大家都按信封的约定解析即可。

5. 反序列化的安全边界：类型信息是一把双刃剑

5.1 Fastjson和“自动类型”留下的教训

提起JSON反序列化的多态，就绕不开fastjson。这个框架在国内使用量极大，性能也很强，但历史上因为“自动类型”机制爆出的反序列化漏洞，可以说是整个行业的一个大课。

Fastjson的 AutoType 机制，本意是让JSON可以携带完整的类信息，反序列化时自动还原成某个具体的类，这和Jackson的 @JsonTypeInfo(use = Id.CLASS) 在功能上异曲同工。坏就坏在它过于“万能”——攻击者只要把JSON里的 @type 指向某个危险类，配合该类的getter/setter或静态方法，就能触发恶意逻辑，甚至直接执行系统命令。

所有反序列化安全问题的本质是同一个道理：反序列化这个动作，本质上是在执行一段由数据驱动的对象构造逻辑。 如果攻击者能控制“构造哪个类”和“用什么参数构造”，他就能在系统里做很多你不想让他做的事。关注热搜词里“fastjson反序列化漏洞”“session反序列化 长城杯线下”这些关键词背后的技术原理，都是这个逻辑。

你要注意，这不是fastjson独有的问题。Jackson的 activateDefaultTyping、Python的 pickle、PHP的 serialize()、Java原生的 ObjectInputStream，全都面临类似风险。区别只在于谁把默认开关打开了。

5.2 一套可落地的安全基线

做了这么多年反序列化相关的工作，我给自己定的安全底线是这几条，分享出来供你参考：

一、不可信来源的数据，永远不要用支持多态的反序列化器去解析。 消息队列入口、外部API回调、用户上传文件，这些通道进来的数据默认是不可信的。如果业务上确实需要多态，那就把类型白名单写得严严实实。

二、类型白名单比黑名单靠谱一万倍。 现在的Jackson提供了 PolymorphicTypeValidator，你可以明确允许哪些包和类可以被多态反序列化：

java复制PolymorphicTypeValidator ptv = BasicPolymorphicTypeValidator.builder()
        .allowIfSubType("com.example.events.")
        .allowIfSubType("com.example.common.")
        .disallowIfNotAllowed()
        .build();

ObjectMapper mapper = JsonMapper.builder()
        .polymorphicTypeValidator(ptv)
        .build();

三、优先用 Id.NAME 而不是 Id.CLASS。 用类名做类型标识，等于把整个类加载入口暴露给了数据。而用 Id.NAME + 白名单别名，攻击者即使伪造 type 字段，也只能在受控的别名集合里打转。

四、设置 defaultImpl 作为兜底。 这个前面说过，它除了防止升级不一致导致的崩溃，还有一个安全作用：类型解析失败时走默认父类，而不是报错或者尝试加载任何人提供的类。

五、从 Java 17 开始，尽量用好模块化带来的封装限制。 很多历史漏洞的Payload都依赖 com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl 这类内部类。模块系统可以限制这些内部类的反射访问，平时没感觉，关键时刻能挡住一条路。

6. 多态序列化在持久化与接口对接中的细节

6.1 三类场景对类型字段的不同要求

同样一个多态对象，落到“数据库字段”“消息队列”“接口返回”三个场景，要求其实不一样。我分别说下。

持久化到数据库的JSON： 你的JSON可能面临长期存储、跨版本升级、被别的系统直接读库等情况。这时类型标识字段必须极其稳定，建议用业务语义明确的名称，比如 ORDER_CREATED，而不是类的简单类名。因为一年后你很可能重构类名，但库里已经存了几千万条旧数据，不可能回改。如果你当初用了 Id.CLASS，类名一改，历史数据全部不可反序列化——这就是教训。

发送到消息队列的JSON： 消息队列是短暂的生命周期，可以容忍“临时加字段”，但不能容忍“类型不兼容”。如果下游反序列化失败，消息就会进入死信队列或触发重试。建议在消息体里放一个 schemaVersion 字段，配合多态类型字段，形成双保险。下游先判断版本，再走对应的解析逻辑；升级的时候先升级下游，再升级上游。

接口返回给前端的JSON： 这种场景我一般反而不推荐多态。前端通常只需要根据一个 type 字段自己决定展示逻辑，返回“拍平”的数据结构更友好。如果后端强行把 @JsonTypeInfo 开起来，前端拿到的JSON里会多出类型字段，反而造成混乱。能用“扁平结构+判别字段”就别用多态序列化，这是接口设计的基本原则。

6.2 数值精度和命名规则的隐藏问题

多态序列化中还有两个特别容易忽略的问题，但从热搜词看，踩的人不少。

第一个是Long整数溢出。 Java的 long（64位）在JSON里被序列化成数字后，JavaScript的 Number 只能精确表示53位以内的整数，超出的部分会丢精度。我见过有项目把雪花算法生成的ID放在事件对象里，前端拿到后后几位数字变成0，排查了大半天。解决方式是给ID字段加 @JsonSerialize(using = ToStringSerializer.class) 强制转字符串，或者在接收端用 Long + Jackson配置处理：

java复制ObjectMapper mapper = new ObjectMapper();
mapper.enable(DeserializationFeature.USE_LONG_FOR_INTS);

第二个是Java Bean属性命名导致的大小写问题。 有开发同学遇到“Java Bean大写字母开头的变量，转JSON后变短横线或变小写”的情况。这是Jackson的命名策略搞的鬼。如果你的字段本身就是首字母大写（这种命名本身不太符合Java规范，但确实会遇到），需要在类上加 @JsonProperty("ProductName") 显式指定，或者用 @JsonNaming 把命名策略设为不处理：

java复制@JsonNaming(PropertyNamingStrategies.LowerCamelCaseStrategy.class)
public class SomeBean {
    public String ProductName; // 需要显式映射
}

多态模型里一旦出现这类字段，排查难度会比普通DTO高很多，因为你不仅要考虑字段本身，还要考虑类型映射是否正确。我在项目里给团队定的规矩是：参与序列化的Java Bean，属性命名必须严格小驼峰，且不能以大写字母开头，否则不给过Code Review。

6.3 性能开销：多态反序列化到底慢多少

有人担心多态序列化带来的性能损耗。我的实测结论是：类型字段本身对性能的影响微乎其微，真正影响性能的是反射解析和类型校验。

对比一下：

数据只是大致参考，但结论很清楚：显式的 @JsonTypeInfo(PROPERTY) 方案，额外开销很小；真正贵的是全局Default Typing和复杂的类名解析。所以性能不该成为你拒绝 @JsonTypeInfo 的理由，倒是该成为你慎用Default Typing的理由。

如果系统对反序列化性能极其敏感，可以考虑用缓存——先把类型标识到Class的映射关系缓存起来，避免每次反序列化时都走注解扫描。Jackson内部其实已经做了不少缓存，但自定义 TypeIdResolver 时的Map缓存还是值得自己维护一遍。

7. 关于多态JSON，我的几条工程建议

写到这里，内容基本已经覆盖了多态序列化的原理、方案、坑点和安全。最后我不做什么总结，就分享几条我自己在项目里踩过坑之后形成的规矩，像老程序员之间递烟聊天那样告诉你。

第一条，多态序列化方案一定要在项目初期就定下来。 后期再想往已经上线跑了一年的事件模型里加类型标识，几乎等于做一次数据库迁移，成本极高。如果你的架构里确定会有多种事件、多种配置、多种任务结构，从第一天就用 @JsonTypeInfo，别想着“等需要的时候再加”。

第二条，类型标识字段名全公司统一。 有人用 type，有人用 eventType，有人用 @type，到了跨部门联调的时候全是泪。订一个公共规范，推荐就叫 type 或 eventType，所有服务的消息体统一遵守。最好出一个公共的Schema定义，各团队照着做。

第三条，新增子类不是改完父类注解就完了。 你需要确认三件事：下游是否能识别新类型？老数据反序列化时是否会走到 defaultImpl？新类型字段有没有超出下游版本能处理的边界？很多线上反序列化问题，不是代码写错了，而是发布顺序和兼容性没想清楚。

第四条，没事别开全局自动类型。 搜索引擎一搜，到处都是“如何配置ObjectMapper让所有多态自动生效”的帖子，好像这样做很高级。但以我经验，全局自动类型只会让你的JSON输出变得复杂、难排查，还把安全风险倍数放大。显式注解虽然写着累，但它逼着你一遍遍想清楚每个类型到底是干嘛的，这才是工程上真正需要的东西。

如果你看完这篇文章，能被提醒到去检查一下自己项目里的多态JSON有没有做兜底、有没有开白名单、有没有统一类型命名，那我这几个小时就没白写。多态序列化这东西，技术含量不高，细节含量极高，希望你能少踩几个我当年踩过的坑。