MyBatis-Flex 与 MyBatis-Plus 能否共存？

Question

MyBatis-Flex 与 MyBatis-Plus 能否在同一个Spring Boot项目中共存？两者均基于 MyBatis 做增强，提供了相似的CRUD封装和插件机制，但在核心组件如SqlSessionFactory、Executor、拦截器实现上存在冲突风险。例如，两者都可能注册自己的分页插件或自动填充功能，导致Bean冲突或行为不可预知。若共存，需精细配置扫描包路径、Mapper注册及插件加载顺序，避免重复代理同一Mapper接口。实际开发中建议统一技术栈，选择其一以降低维护成本。

Answer 1

一、背景与共存可能性分析

在现代Java企业级开发中，MyBatis作为持久层框架被广泛应用。为了提升开发效率，社区衍生出多个增强型ORM框架，其中MyBatis-Plus和MyBatis-Flex是当前较为流行的两个选择。

两者均基于MyBatis核心机制进行功能扩展，提供通用CRUD封装、条件构造器、分页插件、自动填充等高级特性。然而，由于它们都依赖并扩展了MyBatis的核心组件（如SqlSessionFactory、Executor、拦截器链），因此在一个Spring Boot项目中尝试同时引入二者时，极易引发冲突。

从技术角度看，共存并非完全不可行，但需深入理解其底层实现机制，并进行精细化配置管理。

二、核心冲突点深度剖析

• SqlSessionFactory 冲突：两者都会通过各自的starter自动配置一个SqlSessionFactory Bean，若未显式指定主数据源或工厂名称，Spring容器将抛出BeanDefinitionOverrideException。
• 拦截器注册重叠：MyBatis-Plus 的PaginationInterceptor与 MyBatis-Flex 的FlexPageInterceptor均作用于Executor层级，若同时激活，可能导致分页逻辑重复执行或结果错乱。
• Mapper代理冲突：当同一Mapper接口被两个框架的扫描路径覆盖时，可能被双重代理，导致方法调用行为异常，甚至NPE。
• 自动填充机制竞争：两者均有字段自动填充功能（如create_time/update_time），其实现方式均为拦截StatementHandler，若未隔离处理逻辑，易造成值被覆盖或丢失。

三、共存的技术路径与配置策略

若因历史原因必须共存，可通过以下方式进行隔离控制：

1. 明确划分模块边界，使用不同的包路径存放各自Mapper接口。
2. 为每个框架配置独立的SqlSessionFactory和DataSource（或多数据源场景）。
3. 通过@MapperScan注解分别指定扫描路径，并设置factoryRef指向对应工厂。
4. 禁用其中一个框架的自动配置，例如排除MybatisPlusAutoConfiguration。
5. 手动注册拦截器，确保加载顺序可控，避免重复增强。

四、配置示例代码

@Configuration
@MapperScan(basePackages = "com.example.mybatisplus.mapper", sqlSessionFactoryRef = "plusSqlSessionFactory")
public class MyBatisPlusConfig {

    @Bean("plusSqlSessionFactory")
    public SqlSessionFactory plusSqlSessionFactory(@Qualifier("dataSource") DataSource dataSource) throws Exception {
        MyBatisSqlSessionFactoryBean factoryBean = new MyBatisSqlSessionFactoryBean();
        factoryBean.setDataSource(dataSource);
        factoryBean.setPlugins(new Interceptor[]{new PaginationInnerInterceptor(DbType.MYSQL)});
        return factoryBean.getObject();
    }
}
    

@Configuration
@MapperScan(basePackages = "com.example.flex.mapper", sqlSessionFactoryRef = "flexSqlSessionFactory")
public class MyBatisFlexConfig {

    @Bean("flexSqlSessionFactory")
    public SqlSessionFactory flexSqlSessionFactory(@Qualifier("dataSource") DataSource dataSource) {
        FlexSqlSessionFactoryBean factoryBean = new FlexSqlSessionFactoryBean();
        factoryBean.setDataSource(dataSource);
        factoryBean.setPlugins(Arrays.asList(new FlexPageInterceptor()));
        return factoryBean.getObject();
    }
}
    

五、共存风险与建议方案对比表

维度	MyBatis-Plus	MyBatis-Flex	共存风险等级
活跃度	高（GitHub Star > 20k）	中（国内新兴框架）	低
文档完整性	完善	较完整	中
插件兼容性	广泛集成	自研体系	高
多数据源支持	良好	优秀	中
性能优化能力	标准	更细粒度SQL控制	低
学习成本	低	中	中
社区生态	庞大	较小	高
代码生成器	强大	灵活可定制	低
自动填充实现	MetaObjectHandler	AuditManager	高
分页机制	IPage接口 + 拦截器	FxPage + 拦截器	高

六、架构决策流程图

graph TD
            A[是否需要共存?] --> B{项目现状}
            B --> C[新项目]
            B --> D[旧系统迁移/混合维护]
            C --> E[推荐统一技术栈]
            D --> F[评估模块耦合度]
            F --> G[能否物理隔离Mapper?]
            G --> H[是]
            G --> I[否]
            H --> J[配置多SqlSessionFactory + 分离扫描]
            I --> K[重构优先，逐步替换]
            J --> L[测试拦截器行为一致性]
            K --> M[制定迁移路线图]

七、最佳实践建议

尽管技术上可以通过复杂配置实现MyBatis-Plus与MyBatis-Flex共存，但从长期维护性、团队协作和系统稳定性角度出发，强烈建议：

• 在新项目中统一选用单一增强框架，优先考虑社区活跃度与生态成熟度。
• 对于已有系统，若存在双框架并行情况，应制定渐进式迁移计划，逐步收敛至一个主流框架。
• 利用抽象DAO层或Service层屏蔽底层ORM差异，降低替换成本。
• 建立内部技术选型规范，避免“技术碎片化”带来的隐性债务。