事务必须定义在Service层，代表完整业务单元；禁用Controller/DAO层事务；多数据源需分布式事务框架；传播行为默认REQUIRED，隔离级别默认READ_COMMITTED；异常须显式声明rollbackFor。
事务管理在企业级 Java 应用中不是“加个 @Transactional 就完事”，而是贯穿架构设计、分层职责、数据源治理和异常处理的系统性规范。核心在于把事务边界控制权收回到业务语义层，同时确保跨组件、跨数据源场景下的一致性可落地。
事务必须定义在 Service 层，且由业务方法整体包裹
事务边界不能落在 Controller 或 DAO 层。Controller 只负责接收请求、校验参数、调用 Service；DAO 层只做单表 CRUD，不感知事务。Service 方法应代表一个完整业务单元（如“创建订单+扣库存+生成日志”），该方法上声明 @Transactional，保证原子性。
- 避免在 private 方法或非 public 方法上加事务注解——Spring AOP 无法代理
- 同一 Service 内部方法调用不走代理，若需事务传播，应拆分为两个 public Service 方法，或改用 TransactionTemplate 编程式事务
- 读操作（如查询列表）默认不开启事务，除非明确需要一致性快照（如报表统计），此时应指定
propagation = Propagation.REQUIRED并配合适当隔离级别
多数据源场景下禁用默认事务，必须显式管理事务边界
Spring 的 @Transactional 默认只作用于单一 DataSource。对接多个数据库（如订单库 + 用户库 + 日志库）时，声明式事务自动失效，强行使用会导致部分操作提交、部分回滚，引发数据不一致。
- 优先评估是否真需跨库事务：能用最终一致性替代的（如发 MQ 消息通知），就不用强一致
- 确需强一致时，选用 Seata（AT 模式或 TCC 模式）等分布式事务框架，而非自行 try-catch + 手动回滚
- 若仅涉及主从库读写分离，应通过 AbstractRoutingDataSource 动态路由，并确保写库事务不被路由到从库——此时仍属单数据源事务，可正常使用 @Transactional
事务配置需统一约束，禁止自由设置传播行为与隔离级别
不同开发随意设 propagation=REQUIRES_NEW 或 isolation=ISOLATION_SERIALIZABLE，会破坏全局事务语义，也易引发死锁或性能瓶颈。架构规范应强制约定：
立即学习“Java免费学习笔记（深入）”；
- 默认传播行为为
REQUIRED（已存在则加入，不存在则新建），禁止无理由使用REQUIRES_NEW - 默认隔离级别为数据库默认值（通常是 READ_COMMITTED），特殊场景（如防幻读）需经 DBA 评审后才允许提升
- 超时时间统一设为 30 秒（
timeout = 30），防止长事务阻塞连接池和锁资源 - 只读事务（
readOnly = true）仅用于明确无更新的查询方法，有助于数据库优化执行计划
异常处理必须匹配事务回滚策略，不可吞掉业务异常
Spring 默认只对 RuntimeException 及其子类触发回滚。若 Service 方法抛出受检异常（如 IOException、自定义 BusinessException），而未在 @Transactional(rollbackFor = ...) 中声明，事务将不会回滚，造成“部分成功”假象。
- 所有自定义业务异常必须继承
RuntimeException，或在事务注解中显式声明rollbackFor = BusinessException.class - 禁止在 Service 方法内 catch 异常后静默吞掉或转成其他非回滚异常
- 日志记录需覆盖事务开始、关键步骤、异常捕获、回滚/提交结果，便于故障定位
