Oracle事务不生效的硬性前置条件是DataSourceTransactionManager配置错误或@Service缺失，导致事务拦截根本未启动；必须确保连接池支持事务、autoCommit=false、bean正确注册且调用经Spring代理。
DataSourceTransactionManager 配置错误或 @Service 缺失，是 Oracle 场景下事务不生效的硬性前置条件问题——不是“可能失效”，而是“根本不会启动事务拦截”。
Oracle 表引擎不决定事务能力，但连接配置必须启用事务支持
oracle 本身没有 myisam/innodb 这类引擎区分，事务支持由数据库实例和 jdbc 连接参数共同保障。但开发者常忽略两点：
-
DataSource必须使用支持事务的连接池（如 HikariCP、Tomcat JDBC），且不能显式设置autoCommit=true（Spring 事务要求连接初始为autoCommit=false） - Oracle JDBC URL 中若含
defaultRowPrefetch=0或implicitCachingEnabled=true等参数，某些旧驱动版本会干扰事务上下文传递（尤其 Oracle 12c + ojdbc7 场景） - 检查
DataSourceTransactionManager是否真正被 Spring 扫描并注册：它必须是@Bean方法返回的、类型为PlatformTransactionManager的 bean，且名称最好为transactionManager（否则需在@Transactional中显式指定transactionManager = "xxx"）
@Service 缺失或代理对象未被注入
事务方法所在的类如果没有被 Spring 管理，@Transactional 就是纯注释——Oracle 数据库再规范也没用。
- 确认类上有
@Service、@Component或@Repository，且该包被@ComponentScan覆盖（Spring Boot 默认扫描主类所在包及其子包） - 避免手动
new UserService()调用：这种实例绕过 Spring 容器，无代理、无事务拦截 - 若用了 Lombok 的
@RequiredArgsConstructor或构造器注入，确保字段注入的是接口类型（如UserMapper），而非具体实现类（如UserMapperImpl），否则可能因类型不匹配导致代理失败
事务方法调用路径必须经过 Spring 代理
Oracle 不特殊，但它的 JDBC 驱动对事务状态更敏感——自调用失效时，你甚至看不到任何异常日志，只发现数据已提交。
- 同一个类中，
public void doWork() { this.saveToOracle(); }→saveToOracle()上的@Transactional无效 - 即使加了
@EnableAspectJAutoProxy(exposeProxy = true)，也必须用((UserService) AopContext.currentProxy()).saveToOracle()，否则仍是 this 调用 - 更稳妥的做法是拆分：把
saveToOracle()放到独立的@Service类中，并通过@Autowired注入调用
rollbackFor 和 Oracle 特定异常要对齐
Oracle 抛出的常见异常如 SQLException（ORA-00001 唯一约束）、DataIntegrityViolationException，默认不会触发回滚——因为它们包装了受检异常，而 Spring 默认只响应 RuntimeException。
- 务必显式声明：
@Transactional(rollbackFor = {SQLException.class, DataIntegrityViolationException.class}) - 不要捕获后吞掉异常：
try { ... } catch (SQLException e) { log.error(...); }—— 这会让事务“假装成功”提交 - 若业务逻辑里抛出自定义异常（如
InsufficientBalanceException），也要加入rollbackFor，否则 Oracle 的变更已写入连接缓冲区，无法撤回
