Spring与MyBatis整合实战：SqlSessionFactoryBean与事务配置

本文深入剖析了Spring与MyBatis整合中的四大关键陷阱：SqlSessionFactoryBean必须显式指定dataSource以避免多数据源下的自动注入失败；事务管理器必须严格使用与SqlSessionFactoryBean共享同一DataSource的DataSourceTransactionManager，误用JtaTransactionManager将导致@Transactional完全静默失效；@MapperScan必须精准指向Mapper接口包路径，而非XML或实现类路径，否则引发“Invalid bound statement”异常；以及最隐蔽的事务失效场景——同类中自调用因Spring AOP代理机制限制而无法触发事务，需通过合理设计或AopContext.currentProxy()等手段规避。这些看似配置细节的问题，实则直击线上稳定性命脉，稍有疏忽便可能导致数据不一致却无任何报错，值得每一位整合开发者警惕与深究。

SqlSessionFactoryBean 配置必须指定 dataSource，否则启动报 NoUniqueBeanDefinitionException

Spring 容器里如果有多个 DataSource（比如主从、多数据源），SqlSessionFactoryBean 又没显式指定 dataSource，它会尝试自动注入——结果就是找不到唯一 Bean。这不是 MyBatis 的错，是 Spring 的依赖注入机制在“帮忙”失败。

实操建议：

• SqlSessionFactoryBean 的 setDataSource() 必须调用，不能靠 @Autowired 自动装配
• 如果用了 @Configuration 类，直接传入已定义好的 DataSource Bean 引用，别用字段注入
• XML 配置下， 的 ref 值要和 严格一致

常见错误现象：Caused by: org.springframework.beans.factory.NoUniqueBeanDefinitionException: No qualifying bean of type 'javax.sql.DataSource' available

事务管理器必须用 DataSourceTransactionManager，别误配成 JtaTransactionManager

MyBatis 底层走 JDBC，事务边界由 DataSource 控制。用 JtaTransactionManager 不仅不生效，还会导致 @Transactional 完全静默失败——方法执行完不回滚、也不报错，数据就悄悄错了。

实操建议：

• 确认 TransactionManager 类型是 org.springframework.jdbc.datasource.DataSourceTransactionManager
• 构造时必须传入和 SqlSessionFactoryBean 同一个 DataSource 实例，否则事务跨不到 SQL 执行层
• XML 中检查 class="org.springframework.jdbc.datasource.DataSourceTransactionManager"，别手滑写成 JtaTransactionManager

性能影响：用错类型不会拖慢启动，但会让所有 @Transactional 形同虚设，问题往往在线上才发现。

@MapperScan 要扫到接口，不是 XML 或 Mapper 类

很多人把 @MapperScan("com.example.mapper") 写成扫描 XML 文件路径或实现类路径，结果 Spring 找不到任何 Mapper 接口，运行时报 Invalid bound statement (not found)。

实操建议：

• @MapperScan 的 basePackage 值必须是存放 interface 的 Java 包路径，比如 com.example.mapper
• XML 映射文件可以放在 classpath 下任意位置，只要 mapper 标签的 namespace 和接口全限定名一致即可
• 如果用 Maven，确保 XML 文件被正确复制进 target/classes（检查 pom.xml 是否漏了 配置）

容易踩的坑：IDE 里能看到 XML，但打包后缺失，是因为默认不打包 src/main/java 下的非 .java 文件。

事务失效最隐蔽的场景：自调用 + proxy-target-class=false

同一个 Service 类里，A 方法加了 @Transactional，B 方法调用 A 方法——事务根本不会开启。这不是配置问题，是 Spring AOP 代理机制决定的：只有外部 Bean 调用才能触发代理拦截。

实操建议：

• 避免在同一个类内做带事务的方法调用；真要这么做，用 AopContext.currentProxy() 强转后调用（需开启 expose-proxy="true"）
• 确认 @EnableTransactionManagement 没加 proxyTargetClass = false（默认是 true），否则 JDK 动态代理可能绕过某些接口
• 用 @Transactional 的方法不能是 private 或 final，否则代理无法重写

这个点最容易被忽略：日志里看不到报错，SQL 也正常执行，但 rollback 不发生——因为压根没进事务切面。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~