Java企业级事务管理规范的核心是通过分层约定、框架约束与团队共识实现事务边界清晰、行为可预测、异常不穿透、资源不泄漏；明确事务统一置于Service层public方法，禁用self-invocation，跨服务不传播事务，Web层严禁开启事务，读操作用SUPPORTS+readOnly，写操作用REQUIRED，资金类场景显式指定SERIALIZABLE并配锁，所有@Transactional必须显式声明rollbackFor，捕获异常须重抛，事务入口打TRACE日志，多数据源禁止同事务操作不同物理库，跨库一致改用消息+本地事务表，规范嵌入模板、CR清单与CI流水线。
Java 企业级应用中事务管理规范的核心，是让事务边界清晰、行为可预测、异常不穿透、资源不泄漏。不是靠堆注解或硬编码 try-catch，而是通过分层约定 + 框架约束 + 团队共识来落地。
明确事务边界：谁开启、谁提交、谁回滚
Spring 基于代理的声明式事务（@Transactional）只对 public 方法生效，且调用必须走代理对象（不能 self-invocation）。规范应强制规定：
- 事务控制统一放在 Service 层的 public 方法上，DAO 层不加 @Transactional
- 跨服务调用（如 Feign、Dubbo）不传播事务，避免分布式事务陷阱
- 同一类内方法互相调用需拆出新 Bean 或改用编程式事务（TransactionTemplate）
- Web 层（Controller）严禁开启事务，仅负责接收和转发
精准配置传播行为与隔离级别
默认 PROPAGATION_REQUIRED 和 ISOLATION_DEFAULT 不代表“最安全”，而是“最常见”。规范需按场景分级定义：
- 读操作（如查询报表、详情页）→ PROPAGATION_SUPPORTS + 只读标志（readOnly = true），释放数据库连接，提升并发
- 写操作（增删改）→ PROPAGATION_REQUIRED，禁止嵌套事务（避免 PROPAGATION_REQUIRES_NEW 误用）
- 资金类强一致性场景 → 显式指定 ISOLATION_SERIALIZABLE 并配套行锁/乐观锁，同时记录决策依据
- 所有 @Transactional 必须显式声明 rollbackFor，至少包含 Exception.class；禁止仅依赖 unchecked 异常自动回滚
异常处理与日志可观测性
事务是否回滚，取决于异常是否“逃出”事务方法边界，以及 rollbackFor 配置。规范要堵住常见漏洞：
立即学习“Java免费学习笔记（深入）”；
- 捕获异常后未重新抛出，或吞掉异常 → 事务不会回滚 → 要求 catch 块必须 throw 或 log.error 后 rethrow
- 自定义业务异常必须继承 RuntimeException（或显式配置 rollbackFor），避免“检查异常不触发回滚”陷阱
- 每个事务方法入口打 TRACE 日志（含 traceId、method、params），提交/回滚时打 INFO 日志（含结果、耗时、影响行数）
- 在统一异常处理器（@ControllerAdvice）中禁止对已回滚事务做“补偿式重试”，应在 Service 层设计幂等写法
多数据源与分布式事务的兜底策略
单体应用多数据源（如主从库、异构库）不等于分布式事务。规范应划清红线：
- 禁止在同一个 @Transactional 中操作多个物理数据源（JDBC 连接不同）→ Spring 无法保证原子性
- 确需跨库一致 → 改用可靠消息（如 RocketMQ 事务消息）+ 本地事务表，而非 XA 或 Seata AT 模式（除非全链路可控）
- 分库分表场景下，事务仅限单分片内；跨分片操作必须设计为最终一致性，并提供对账与修复能力
- 所有外部系统调用（短信、支付、ES 写入）视为“尽力而为”，失败走异步补偿，不在主事务中同步阻塞
规范不是文档墙，而是嵌入到代码模板、CR 检查清单、SonarQube 规则和 CI 流水线中的活约束。每次新增事务逻辑，都应回答三个问题：边界是否唯一？异常是否透出？回滚是否确定？答不上来，就先别 merge。
