MyBatis-Plus在若依框架中的正确打开方式：3个关键配置点与性能优化技巧

最新推荐文章于 2026-04-24 10:05:30 发布

原创

最新推荐文章于 2026-04-24 10:05:30 发布 · 188 阅读

文章标签：

#若依框架 #MyBatis-Plus #Java框架集成 #性能优化

若依框架与MyBatis-Plus的深度整合：从平滑对接到性能飞跃

如果你正在使用若依（RuoYi）这个优秀的开源后台管理系统，同时又对MyBatis-Plus（简称MP）的便捷性念念不忘，那么将它们二者结合的想法一定在你脑海中出现过不止一次。毕竟，谁不想在享受若依成熟权限体系和优雅架构的同时，还能用上MP那“懒人福音”般的CRUD操作呢？但真正动手时，你会发现这并非简单的1+1组合——若依自身已经有一套完整的MyBatis配置体系，MP的介入需要一些巧妙的“手术”，而不是粗暴的替换。

我经历过几次从零开始的整合，也踩过不少坑。最让人头疼的不是代码写不出来，而是配置看起来都对，但运行时各种绑定失败、插件失效的诡异问题。这篇文章就是把这些经验系统化，告诉你如何正确、优雅且高性能地在若依框架中集成MyBatis-Plus。我们不会只停留在“怎么配”，而是深入“为什么这么配”，并分享几个能显著提升生产环境性能的实战技巧。

1. 依赖管理的艺术：避免版本冲突的隐形陷阱

整合的第一步永远是处理依赖。很多人以为只要在pom.xml里加上MyBatis-Plus的starter就万事大吉，结果一运行就发现各种ClassNotFoundException或者方法签名不匹配。若依框架本身依赖了MyBatis和PageHelper，而MP官方明确建议：引入MyBatis-Plus后，不要再次引入MyBatis及MyBatis-Spring，以避免版本差异导致的问题。

这意味着我们需要做一次精细的依赖梳理。打开你的若依项目，找到主pom.xml，你会看到类似这样的依赖结构：

<!-- 若依核心依赖 -->
<dependency>
    <groupId>org.mybatis.spring.boot</groupId>
    <artifactId>mybatis-spring-boot-starter</artifactId>
    <version>${mybatis.version}</version>
</dependency>

<!-- PageHelper分页插件 -->
<dependency>
    <groupId>com.github.pagehelper</groupId>
    <artifactId>pagehelper-spring-boot-starter</artifactId>
    <version>${pagehelper.version}</version>
</dependency>

第一步是移除原生的MyBatis starter，替换为MyBatis-Plus的starter。但这里有个细节：不要直接删除mybatis-spring-boot-starter依赖，而是通过<exclusion>标签排除它，因为其他模块可能间接引用了它。更稳妥的做法是统一在父POM中管理。

<!-- 引入MyBatis-Plus -->
<dependency>
    <groupId>com.baomidou</groupId>
    <artifactId>mybatis-plus-boot-starter</artifactId>
    <version>3.5.3.1</version> <!-- 使用当时最新稳定版 -->
</dependency>

<!-- 处理PageHelper的传递依赖 -->
<dependency>
    <groupId>com.github.pagehelper</groupId>
    <artifactId>pagehelper-spring-boot-starter</artifactId>
    <version>${pagehelper.version}</version>
    <exclusions>
        <exclusion>
            <groupId>org.mybatis</groupId>
            <artifactId>mybatis</artifactId>
        </exclusion>
        <exclusion>
            <groupId>org.mybatis</groupId>
            <artifactId>mybatis-spring</artifactId>
        </exclusion>
    </exclusions>
</dependency>

注意：这里排除的是PageHelper依赖的MyBatis，而不是全局排除。如果项目其他地方直接依赖了MyBatis，也需要同样处理。

完成依赖调整后，建议执行mvn dependency:tree命令，检查依赖树中是否还有重复的MyBatis版本。理想状态下，整个项目应该只通过mybatis-plus-boot-starter引入唯一的MyBatis核心库。

我遇到过一种情况：依赖检查都通过了，但启动时还是报SqlSessionFactory相关错误。后来发现是若依的某个工具模块单独引用了旧版MyBatis。这时需要全局搜索mybatis依赖，确保所有地方都做了排除或版本对齐。

2. 核心配置点的精准替换：让两个框架和谐共处

依赖问题解决后，真正的挑战才开始。若依框架在ruoyi-framework模块中有一个MyBatisConfig配置类，它手动创建了SqlSessionFactoryBean。而MyBatis-Plus需要的是它的子类MybatisSqlSessionFactoryBean。这个差异看似微小，却是导致后续所有插件失效的根源。

2.1 SqlSessionFactoryBean的正确替换

找到若依中的MyBatisConfig类（通常在com.ruoyi.framework.config包下），你会看到类似这样的代码：

@Bean
public SqlSessionFactory sqlSessionFactory(DataSource dataSource) throws Exception {
    String typeAliasesPackage = env.getProperty("mybatis.typeAliasesPackage");
    String mapperLocations = env.getProperty("mybatis.mapperLocations");
    String configLocation = env.getProperty("mybatis.configLocation");
    
    // 关键修改点：将SqlSessionFactoryBean改为MybatisSqlSessionFactoryBean
    final MybatisSqlSessionFactoryBean sessionFactory = new MybatisSqlSessionFactoryBean();
    
    sessionFactory.setDataSource(dataSource);
    sessionFactory.setTypeAliasesPackage(typeAliasesPackage);
    sessionFactory.setMapperLocations(resolveMapperLocations(mapperLocations));
    sessionFactory.setConfigLocation(new DefaultResourceLoader().getResource(configLocation));
    
    return sessionFactory.getObject();
}

这个修改解决了第一个大坑：Invalid bound statement (not found) 错误。当使用原生的SqlSessionFactoryBean