MyBatis-Plus中多List泛型TypeHandler处理冲突问题解析

问题背景

在使用MyBatis-Plus进行数据库操作时，经常会遇到需要将数据库中的JSON字符串转换为Java对象集合(List)的场景。当系统中存在多个不同类型的List集合需要处理时，开发者可能会遇到TypeHandler处理冲突的问题。

典型场景

假设我们有以下业务需求：

1. 需要将数据库中的JSON字符串转换为List<WarehouseCheckout.OriginalInfo>
2. 同时还需要处理另一种JSON字符串转换为List<ItemInfo.LeftAmountInfo>

按照常规做法，开发者会为每种类型创建对应的TypeHandler实现类，并通过@TableField注解指定处理器。然而实际运行时会发现，只有最先被使用的TypeHandler会生效，后续的List类型处理都会被错误地转换为第一个处理的类型。

问题根源分析

这个问题的本质在于MyBatis对TypeHandler的缓存机制。当MyBatis遇到List.class类型时，它会：

1. 根据@MappedTypes(List.class)注解找到所有注册的TypeHandler
2. 但MyBatis内部会将这些处理器缓存起来，且对于相同的Java类型(List.class)只保留一个处理器
3. 导致后续的List类型处理都会使用第一个被缓存的处理器

解决方案

方案一：使用包装类型替代直接List

public class OriginalInfoList {
    private List<WarehouseCheckout.OriginalInfo> list;
    // getter/setter
}

public class LeftAmountInfoList {
    private List<ItemInfo.LeftAmountInfo> list;
    // getter/setter
}

然后为每个包装类型创建对应的TypeHandler，这样MyBatis就能正确区分不同类型的集合。

方案二：使用自定义List子类

public class OriginalInfoList extends ArrayList<WarehouseCheckout.OriginalInfo> {}

public class LeftAmountInfoList extends ArrayList<ItemInfo.LeftAmountInfo> {}

然后为这些自定义List类型创建TypeHandler。

方案三：调整TypeHandler注册方式

在MyBatis配置中明确指定每种List类型对应的处理器：

@Configuration
public class MyBatisConfig {
    @Bean
    public ConfigurationCustomizer configurationCustomizer() {
        return configuration -> {
            configuration.getTypeHandlerRegistry().register(
                new CheckoutOriginalListHandler(), 
                List<WarehouseCheckout.OriginalInfo>.class
            );
            configuration.getTypeHandlerRegistry().register(
                new ItemLeftAmountListHandler(),
                List<ItemInfo.LeftAmountInfo>.class
            );
        };
    }
}

最佳实践建议

1. 避免直接使用List.class作为映射类型：这会导致处理器冲突
2. 为每种集合类型创建明确的类型定义：无论是包装类还是子类，都能帮助MyBatis正确识别
3. 考虑使用泛型工具类：可以创建一个通用的JsonTypeHandler，通过构造函数传入具体类型
4. 测试验证：确保在集成测试中覆盖所有类型的集合处理场景

总结

MyBatis-Plus在处理多List泛型TypeHandler时出现的问题，本质上是MyBatis类型系统对泛型集合处理的一个限制。通过使用明确的类型定义或调整注册方式，可以有效地解决这个问题。在实际项目中，建议采用方案一或方案二，这样代码更加清晰且易于维护。