spring事务注解不依赖system属性，所谓“system属性滞后导致事务不回滚”是误解；真实原因包括异常未抛出、受检异常未配置rollbackfor、非public方法、同类自调用、事务管理器未正确配置等。
Spring 事务注解（@Transactional）本身不依赖 System 属性，也不存在“System 属性滞后导致事务不回滚”这一技术现象。这是对 Spring 事务机制的常见误解——Spring 的事务行为由代理机制、异常类型、调用方式、传播行为等决定，与 System.getProperty() 或 JVM 启动参数等系统属性无直接关联。
为什么有人会误以为是“System 属性滞后”？
实际中，这类说法往往源于以下几种混淆场景：
-
配置加载时机错觉：比如在
@PostConstruct或静态块中读取了未初始化的配置（如从application.properties绑定的值），误以为是 System 属性“没跟上”，实则是 Spring Boot 配置绑定尚未完成； -
条件化事务被忽略：使用了
@ConditionalOnProperty(name = "tx.enabled", havingValue = "true")等条件注解，但对应 property 未正确配置或拼写错误，导致整个@Transactional方法根本没被 Spring 扫描到； -
Profile 激活延迟：通过
-Dspring.profiles.active=prod控制事务管理器启用，但开发环境未激活对应 profile，造成事务管理器（PlatformTransactionManager）未注册，事务注解“形同虚设”； -
自定义 TransactionManager 名称未匹配：代码中写了
@Transactional("myTxMgr")，但实际 Bean 名为transactionManager，而该名称又依赖某 System 属性动态生成（如System.getProperty("tx.bean.name")），若该属性未设置或设置过晚，就会找不到事务管理器。
真正影响事务回滚的核心因素
请优先排查这些确定性原因：
- 异常未抛出或被吞掉：方法内 try-catch 了异常且未 re-throw，或 catch 后静默处理；
-
抛出的是受检异常（Checked Exception）：默认不触发回滚，需显式声明
rollbackFor = Exception.class； - 方法不是 public：private/protected/final 方法无法被代理，事务失效；
- 同类中自调用（this.xxx()）：绕过代理对象，事务切面不生效；
-
事务管理器未正确配置或未注入：检查容器中是否存在且 Bean 名匹配，尤其多数据源场景下易配错
transactionManagerRef。
如何验证事务是否真正生效
不要依赖日志或“看起来没报错”，而是做可验证的动作：
- 在
@Transactional方法内故意抛出new RuntimeException("force rollback")，观察数据库变更是否全部撤销； - 开启 DEBUG 日志：
logging.level.org.springframework.transaction=DEBUG，确认是否打印Creating new transaction和Initiating transaction rollback； - 检查事务管理器 Bean 是否存在：
@Autowired private PlatformTransactionManager txManager;，启动时报 NPE 就说明根本没配好。
只要排除上述真实原因，事务就能按预期回滚。所谓“System 属性滞后”，通常只是表象，背后一定是配置加载顺序、Bean 创建时机或代理机制被破坏所致。
