关键在于“在哪儿提交、由谁控制、是否在正确上下文中提交”：推荐使用spring声明式事务（@transactional），由框架自动管理commit/rollback；若手动管理，须严格遵循获取连接→禁用自动提交→复用同一连接→显式提交或回滚→归还连接的流程。
Java 中调用 commit() 提交事务本身不难，但真正保障业务数据一致性，关键不在“怎么写 commit()”，而在于“在哪儿提交、由谁控制、是否在正确上下文中提交”。直接裸调 connection.commit() 容易出错，尤其在多层调用、异常分支、连接复用（如连接池）场景下极易导致数据不一致或连接泄漏。
使用声明式事务（推荐 Spring @Transactional）
这是最常用也最安全的方式，由框架自动管理 commit/rollback，开发者只需关注业务逻辑。
- 在 Service 层方法上加
@Transactional注解，Spring 会在方法正常结束时自动 commit；遇到未捕获的运行时异常（RuntimeException及其子类）时自动 rollback - 确保该方法被 Spring 容器管理（即通过注入调用，不是 new 出来的对象调用），否则注解无效
- 如需自定义回滚规则，可用
@Transactional(rollbackFor = Exception.class)指定对受检异常也回滚 - 避免在事务方法内吞掉异常（如 try-catch 后不抛出），否则 Spring 无法感知失败，会错误 commit
手动管理事务（JDBC 原生方式）
适合简单脚本、测试或必须绕过框架的场景，但需严格遵循“获取连接 → 关闭自动提交 → 执行 SQL → 显式 commit/rollback → 关闭资源”流程。
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 从 DataSource 获取 Connection 后，立即调用
conn.setAutoCommit(false) - 所有相关 SQL 操作（增删改）必须复用同一个 Connection 对象，不能跨连接
- 成功完成全部操作后，调用
conn.commit()；任一环节出错，必须在 catch 或 finally 中调用conn.rollback() - 务必在 finally 块中调用
conn.close()（连接池环境下实际是归还连接，非销毁）
注意事务边界与传播行为
多个事务方法相互调用时，传播行为决定新事务是否开启、如何嵌套，直接影响 commit 是否生效。
-
REQUIRED（默认）：有事务则加入，无则新建 —— 最常用，适合多数业务组合 -
REQUIRES_NEW：总是挂起当前事务，新建独立事务 —— 适合日志记录、异步通知等需独立成败的子操作 - 避免
SUPPORTS或NOT_SUPPORTED用于核心写操作，它们可能让关键更新脱离事务保护
常见一致性陷阱与规避
即使写了 commit()，仍可能因设计疏漏破坏一致性：
- 跨数据库操作无法靠单个 commit 保证原子性 —— 需用分布式事务（如 Seata、XA）或最终一致性方案（消息表 + 补偿）
- 事务中调用外部 HTTP 接口成功但 DB 写入失败，或反之 —— 应将外部调用移出事务，或引入本地消息表+可靠消息
- 同一事务内多次查询同一数据却得到不同结果（幻读/不可重复读）—— 根据隔离级别调整（如设为
REPEATABLE_READ），但注意性能影响 - 长时间事务阻塞其他操作 —— 拆分大事务，避免在事务中做耗时操作（如文件处理、远程调用）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
