大厂（尤其是阿里、字节、腾讯、美团、京东等头部互联网公司）在内部规范或代码审查中，往往不推荐（甚至部分团队明令禁止）在业务代码中大量/随意使用 @Transactional 声明式事务，而更倾向于编程式事务（如 TransactionTemplate）或手动控制 + 补偿机制。
这不是说 @Transactional 本身有问题，而是在超大规模、高并发、长链路、复杂业务场景下，它的“便利性”很容易变成“隐蔽雷区”，导致线上故障、性能瓶颈、排查困难。
大厂最常诟病的几大核心问题（真实踩坑总结）
| 问题排名 | 具体问题 | 为什么在大厂致命（真实影响） | 典型线上case / 后果 | 大厂常见规避方式 |
|---|---|---|---|---|
| 1 | 事务范围过大（大事务 / 长事务） | 方法里塞了太多非数据库操作（RPC、发MQ、写Redis、调用第三方、日志打印、循环查询等），导致事务持有数据库连接时间过长 | 数据库连接池耗尽 → 雪崩、锁超时、死锁、慢SQL堆积、回滚时间长（几分钟甚至超时） | 强制把非DB操作移出事务，只包最核心的DB操作 |
| 2 | 事务失效场景太多，隐蔽性极强 | 自调用失效、非public失效、异常被捕获不抛、传播行为写错、多数据源失效、嵌套混乱等，代码 review 很难一眼看穿 | 以为加了事务实际没生效 → 数据不一致、脏数据、资损 | 禁止声明式，强制编程式（显式可见） |
| 3 | 传播行为（propagation）误用 | 默认 REQUIRED 容易导致事务嵌套混乱；REQUIRES_NEW / NESTED 用错导致挂起/保存点异常；SUPPORTS/MANDATORY 写反抛异常 | 外层事务意外回滚子事务、子事务独立性丢失、死锁 | 极少用嵌套，优先 REQUIRED 或编程式隔离 |
| 4 | 隔离级别 & 锁竞争问题 | 默认隔离级别 + 大事务 → 行锁/表锁/间隙锁持有时间长，高并发下热点行锁爆炸 | 下单/秒杀/库存扣减场景锁等待超时、吞吐暴跌 | 降隔离级别 + 缩短事务 + 异步补偿 |
| 5 | 分布式/多数据源场景天然不友好 | @Transactional 是本地事务，跨库/跨服务天然失效；Seata 等分布式事务框架又引入额外复杂度 | 微服务下数据最终不一致、补偿失败资损 | 优先 Saga/TCC + MQ 最终一致性 |
| 6 | 可观测性 & 排查难度极高 | 事务边界不显式，异常栈不明显，慢查询/死锁日志难关联到具体方法；AOP 黑盒多 | 故障定位时间从分钟拉到几天甚至一周 | 编程式事务边界清晰，日志/埋点好打 |
一句话总结大厂心态：
“声明式事务把事务管理隐藏在注解里，看似省代码，实际把‘事务边界’这个最重要、最容易出事的信息隐藏了，导致代码不可读、不可控、不可预测。”
大厂主流替代方案（2025–2026 真实规范）
- 首选：编程式事务
TransactionTemplate（阿里、字节、美团最常见）
@Autowired
private TransactionTemplate transactionTemplate;
public void createOrder(Order order) {
transactionTemplate.execute(status -> {
try {
// 只放最核心的数据库操作，范围极小
orderDao.insert(order);
itemDao.deductStock(order.getItemId(), order.getQuantity());
return true;
} catch (Exception e) {
status.setRollbackOnly();
throw e;
}
});
}优点：边界显式可见、范围可控、异常处理清晰、可灵活嵌套/拆分。
- 第二选择：手动 Connection + try-finally（极致性能/高并发场景，如秒杀） 手动获取 Connection，手动 commit/rollback。
- 非核心链路：最终一致性 + 补偿（MQ + 幂等 + 定时对账）
- 下单 → 发 MQ → 库存服务消费扣减（失败重试/人工补偿）
- 支付成功 → 异步发消息更新订单状态
- 极少数强一致场景：用 Seata / DTM 等分布式事务框架（但也尽量避免）
大厂内部规范的典型表述（摘自公开分享/规范）
- “禁止在 service 层大范围使用 @Transactional，事务范围必须控制在 DAO 层或最小业务单元。”
- “所有事务必须显式可见，禁止隐式事务。”
- “事务方法禁止包含 RPC、MQ 发送、第三方调用、大量循环、非DB IO。”
- “长事务一律拆解为最终一致性。”
所以结论：
大厂不是反对事务，而是反对“用注解偷懒，把事务这个高风险点隐藏起来”。
在小项目/中台/原型中 @Transactional 没问题，很方便；但在大厂这种“年交易笔数亿级、资损一单上百万、故障容忍度极低”的环境下，它的风险收益比太差了。
你的项目是中大型业务吗？有没有遇到过因为 @Transactional 引发的线上问题？如果有具体场景，我可以帮你分析怎么改成更稳的写法。
