sqlsessionfactorybean 必须显式指定 datasource，否则多数据源时会因 spring 自动注入失败而抛 nouniquebeandefinitionexception；事务管理器必须为 datasourcetransactionmanager 且与 sqlsessionfactorybean 共享同一 datasource；@mapperscan 应扫描 mapper 接口包路径；自调用事务方法不生效是因 spring aop 代理机制限制。
SqlSessionFactoryBean 配置必须指定 dataSource，否则启动报 NoUniqueBeanDefinitionException
Spring 容器里如果有多个 DataSource（比如主从、多数据源），SqlSessionFactoryBean 又没显式指定 dataSource，它会尝试自动注入——结果就是找不到唯一 Bean。这不是 MyBatis 的错，是 Spring 的依赖注入机制在“帮忙”失败。
实操建议：
-
SqlSessionFactoryBean的setDataSource()必须调用，不能靠 @Autowired 自动装配 - 如果用了
@Configuration类，直接传入已定义好的DataSourceBean 引用，别用字段注入 - XML 配置下，
<property name="dataSource" ref="xxxDataSource"></property>的ref值要和<bean id="xxxDataSource"></bean>严格一致
常见错误现象：Caused by: org.springframework.beans.factory.NoUniqueBeanDefinitionException: No qualifying bean of type 'javax.sql.DataSource' available
事务管理器必须用 DataSourceTransactionManager，别误配成 JtaTransactionManager
MyBatis 底层走 JDBC，事务边界由 DataSource 控制。用 JtaTransactionManager 不仅不生效，还会导致 @Transactional 完全静默失败——方法执行完不回滚、也不报错，数据就悄悄错了。
立即学习“Java免费学习笔记（深入）”；
实操建议：
- 确认
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是否漏了<resources></resources>配置）
容易踩的坑：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 不发生——因为压根没进事务切面。
