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

若依框架与MyBatis-Plus的深度整合：从零到一的架构升级与性能调优实战

最近在几个企业级项目中，我频繁遇到一个技术选型问题：团队已经基于若依框架搭建了基础架构，但随着业务复杂度提升，原生的MyBatis在开发效率和维护性上逐渐显得力不从心。这时候，很多开发者会想到引入MyBatis-Plus来提升数据层开发体验，但实际操作起来却发现远没有想象中那么简单——依赖冲突、配置不生效、插件失效等问题接踵而至。

如果你也正面临这样的困境，或者计划在新项目中采用若依+MyBatis-Plus的技术栈，那么这篇文章正是为你准备的。我不会简单重复官方文档的内容，而是基于多个真实项目的实战经验，带你深入理解这两个框架整合的核心要点，特别是那些容易被忽略但至关重要的配置细节。更重要的是，我会分享如何在这种整合基础上进行性能优化，让你的数据层不仅开发高效，而且运行稳定。

1. 环境准备与依赖管理的艺术

在开始整合之前，我们需要对若依框架的依赖结构有清晰的认识。若依作为一个成熟的企业级快速开发平台，其依赖管理相对复杂，特别是当我们要引入MyBatis-Plus时，必须处理好版本兼容性问题。

1.1 依赖冲突的精准排查

若依框架默认集成了MyBatis和PageHelper，而MyBatis-Plus官方明确建议：引入MyBatis-Plus后不应再引入MyBatis，以避免版本差异导致的问题。但直接移除MyBatis依赖可能会引发连锁反应。

首先检查你的pom.xml，若依的依赖结构通常如下：

<!-- 若依核心依赖 -->
<dependency>
    <groupId>com.ruoyi</groupId>
    <artifactId>ruoyi-common</artifactId>
    <version>${ruoyi.version}</version>
</dependency>

<!-- MyBatis依赖（需要处理） -->
<dependency>
    <groupId>org.mybatis.spring.boot</groupId>
    <artifactId>mybatis-spring-boot-starter</artifactId>
    <version>2.2.0</version>
</dependency>

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

这里的关键在于PageHelper，它内部依赖了MyBatis。如果你只是简单移除MyBatis starter，PageHelper会因为找不到MyBatis而报错。正确的做法是通过<exclusions>标签排除传递依赖：

<dependency>
    <groupId>com.github.pagehelper</groupId>
    <artifactId>pagehelper-spring-boot-starter</artifactId>
    <version>1.4.1</version>
    <exclusions>
        <exclusion>
            <groupId>org.mybatis</groupId>
            <artifactId>mybatis</artifactId>
        </exclusion>
        <exclusion>
            <groupId>org.mybatis</groupId>
            <artifactId>mybatis-spring</artifactId>
        </exclusion>
    </exclusions>
</dependency>

注意：不同版本的PageHelper可能依赖结构略有不同，建议使用mvn dependency:tree命令查看完整的依赖树，确保所有MyBatis相关依赖都被正确排除。

1.2 MyBatis-Plus版本选择策略

MyBatis-Plus的版本选择需要考虑与Spring Boot和若依框架的兼容性。根据我的经验，以下版本组合最为稳定：

添加MyBatis-Plus依赖时，建议使用最新的稳定版本：

<dependency>
    <groupId>com.baomidou</groupId>
    <artifactId>mybatis-plus-boot-starter</artifactId>
    <version>3.5.3.1</version>
</dependency>

<!-- 代码生成器（可选但推荐） -->
<dependency>
    <groupId>com.baomidou</groupId>
    <artifactId>mybatis-plus-generator</artifactId>
    <version>3.5.3.1</version>
</dependency>

1.3 配置文件的平滑过渡

若依框架的application.yml中通常已经配置了MyBatis相关设置。我们需要将这些配置迁移到MyBatis-Plus的配置项中，同时保持向后兼容：

# 原若依MyBatis配置
mybatis:
  mapper-locations: classpath*:mapper/**/*.xml
  type-aliases-package: com.ruoyi.**.domain
  config-location: classpath:mybatis/mybatis-config.xml

# MyBatis-Plus配置（新增）
mybatis-plus:
  mapper-locations: ${mybatis.mapper-locations}
  type-aliases-package: ${mybatis.type-aliases-package}
  configuration:
    # 保持与原有配置一致
    map-underscore-to-camel-case: true
    cache-enabled: true
  global-config:
    db-config:
      id-type: auto
      logic-delete-field: delFlag  # 若依使用的逻辑删除字段
      logic-delete-value: 2
      logic-not-delete-value: 0

这里有个细节需要注意：若依框架通常使用delFlag字段作为逻辑删除标识，值为2表示已删除，0表示未删除。我们需要在MyBatis-Plus的全局配置中对应设置。

2. 核心配置点的深度解析与实战

依赖问题解决后，真正的挑战才刚刚开始。MyBatis-Plus在若依框架中的集成，有三个关键配置点决定了整合的成败。

2.1 SqlSessionFactoryBean的替换：从陷阱到解决方案

这是整合过程中最常见的坑。若依框架自己配置了SqlSessionFactoryBean，而MyBatis-Plus需要的是MybatisSqlSessionFactoryBean。这两个类虽然名字相似，但功能上有本质区别。

先看看若依原生的配置类（通常位于MyBatisConfig.java）：

@Configuration
public class MyBatisConfig {
    
    @Bean
    public SqlSessionFactory sqlSessionFactory(