同类内this调用会使@Transactional完全失效，因Spring AOP代理未生效；必须通过注入其他Bean调用或改用编程式事务。
同类内方法调用会导致 @Transactional 完全失效
这是最常踩的坑：在同一个 @Service 类里，用 this.saveLog() 方式调用另一个带 @Transactional 的方法，Spring 代理根本不会生效。因为 Spring AOP 是基于代理对象实现的，this 指向的是原始对象，不是被增强的代理实例。
常见错误现象：saveLog() 方法上明明写了 @Transactional(propagation = Propagation.REQUIRES_NEW)，但主事务一回滚，日志也跟着丢了；或者日志保存成功了，却报 No transaction in progress 异常。
- 必须把嵌套事务逻辑拆到**另一个 Spring 管理的 Bean 中**（比如新建
LogService），再通过@Autowired注入调用 - 不能靠私有方法、静态方法或
this.调用绕过代理机制 - 如果非要留在同类中，只能改用编程式事务（
TransactionTemplate），但会破坏声明式事务的简洁性
Propagation.REQUIRED 是默认行为，但不等于“总是共享同一事务”
@Transactional 默认使用 Propagation.REQUIRED，但它只在**跨 Bean 调用且走代理路径时才生效**。很多人误以为只要加了注解，嵌套调用就自动合并事务——其实前提是调用链经过 Spring 代理。
典型场景：用户注册（主事务）要同步写操作日志（希望独立提交）。若日志方法也用 REQUIRED 且正确注入，则它会加入主事务；若主事务失败，日志也会被回滚——这往往不符合业务预期。
- 需要“失败不影响”的日志/通知类操作，必须显式指定
propagation = Propagation.REQUIRES_NEW -
REQUIRES_NEW会挂起当前事务，开启全新事务，有自己的连接和隔离边界 - 注意性能开销：每次
REQUIRES_NEW都可能触发新数据库连接获取，高并发下需评估连接池压力
NESTED 依赖数据库保存点，不是所有环境都可用
Propagation.NESTED 表面看是“子事务”，实际是利用 JDBC Savepoint 实现的单物理事务内的回滚锚点。它既不像 REQUIRED 那样完全绑定外层，也不像 REQUIRES_NEW 那样彻底隔离。
容易忽略的限制：NESTED 在 HikariCP + MySQL 8.0 下可用，但在某些云数据库（如阿里云 PolarDB 兼容版早期版本）、部分 PostgreSQL 只读副本、或启用了连接池预编译语句的场景中，setSavepoint() 可能抛出 SQLFeatureNotSupportedException。
- 确认数据库驱动支持 JDBC 3.0+ 且未禁用保存点功能
- Spring Boot 3.x 默认 HikariCP，需检查
hikari.connection-init-sql是否清空了保存点上下文 - 若用 JTA 分布式事务，
NESTED可能被降级为REQUIRED，具体取决于 JTA 提供商实现
rollbackFor 和 noRollbackFor 必须和传播行为协同设计
事务是否回滚，不仅取决于传播行为，还受异常类型控制。@Transactional 默认只对 RuntimeException 及其子类回滚，对 Exception（如 IOException、SQLException）不回滚——这点和 Propagation 组合时极易出错。
例如：一个 REQUIRES_NEW 日志方法内部抛出 IOException，若没配 rollbackFor = Exception.class，事务会静默提交，导致“日志写了一半就停了”这种脏数据。
- 所有涉及数据库写入的
@Transactional方法，建议显式声明rollbackFor = Exception.class - 若某方法明确不想因特定异常回滚（如业务校验失败应返回提示而非回滚），用
noRollbackFor = BusinessException.class - 注意：异常必须“逃出方法边界”才会触发回滚；被
try-catch吞掉的异常，Spring 根本感知不到
Propagation 就只是个摆设。 
