事务本质是保障acid：原子性靠undo log回滚，一致性靠约束校验，隔离性靠mvcc/锁，持久性靠redo log；spring @transactional仅是jdbc事务的封装代理，非魔法。
Java 事务是大厂面试高频考点，配教程要聚焦“原理+场景+坑点”三层结构，不堆概念，直击面试官想听的逻辑链。
紧扣 ACID 和传播行为讲清楚“为什么需要事务”
面试官常问“没事务会怎样”，得用具体例子说明：比如转账时扣款成功但加款失败，数据不一致。重点讲清数据库层面的原子性（undo log）、一致性（约束校验）、隔离性（MVCC/锁）、持久性（redo log）如何协同工作。Spring 的 @Transactional 不是魔法，它只是对底层 JDBC 或 JPA 事务的封装——这点必须点明。
- 传播行为（PROPAGATION_REQUIRED、REQUIRES_NEW 等）必须结合调用栈画图解释，比如内层方法抛异常，外层是否回滚，取决于传播类型和异常类型
- 只读事务（readOnly=true）不是性能银弹，它主要提示数据库优化器走只读路径，对 MySQL InnoDB 作用有限，别神化
手写代码演示事务失效的典型场景
光背“this 调用导致代理失效”不够，要现场写两行代码对比：
- 正常情况：serviceA.methodA() → 调用 serviceB.update()（@Transactional 方法），事务生效
- 失效情况：serviceA.methodA() 内直接调用 this.update()，此时没有走 Spring 代理，@Transactional 被忽略
- 补充：自注入（@Autowired ServiceA self）或 ApplicationContext 获取 Bean 是绕过方式，但要说明循环依赖风险
结合分布式事务讲清取舍逻辑
大厂必问“本地事务 vs Seata/XA/TCC”，不能只列名词。重点说清：
- XA 协议强一致但性能差，适合银行核心系统；TCC 业务侵入性强但可控，适合电商下单+扣库存+发券链路
- Seata AT 模式本质是“自动补偿”，通过 undo_log 表记录前镜像，回滚时反向生成 SQL——这比口头说“AT 是自动模式”更有说服力
- 强调最终一致性不是妥协，而是权衡：消息队列+本地事务表+定时校验，比强一致更实用
带一句真实调试经验收尾
比如：“线上查事务不回滚，先看日志里有没有 ‘TransactionAspectSupport’ 相关输出，再确认异常是否被 try-catch 吞掉，最后检查方法是不是 private 或 final —— 这三步覆盖 90% 失效问题。”
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
