结论：ThinkPHP 6/8 的 Db::startTrans() 不支持真正的嵌套事务，仅通过 transTimes 计数器模拟层级，实际依赖 PDO 单层事务机制；所有 startTrans() 共享同一事务上下文，仅最外层 commit()/rollback() 生效，内层操作无效；需手动执行 SAVEPOINT 相关 SQL 实现局部回滚。
ThinkPHP 的 startTrans 不支持真正的嵌套事务
直接说结论：ThinkPHP 6/8 的 Db::startTrans() 或模型的 startTrans() 并不实现底层数据库的嵌套事务（如 PostgreSQL 的 savepoint 或 MySQL 的 nested transaction），它只是用一个静态计数器模拟“嵌套”行为。一旦外层 commit() 或 rollback() 被调用，整个事务状态就终结了，内层的 commit() 实际上什么也不做，rollback() 则会回滚全部。
常见错误现象：
— 内层事务调用了 rollback()，但外层仍继续执行并 commit()，结果数据却已丢失
— 多个方法各自调用 startTrans()，以为能独立控制，实际共享同一事务上下文
- 真正起作用的只有最外层的
startTrans()和最终的commit()/rollback() - 所有中间的
startTrans()只是把内部计数器 +1，commit()只是 -1，直到归零才真正提交 - 只要任意一层调用
rollback()，计数器被重置，后续所有commit()都无效
想实现逻辑上的“嵌套回滚”，得手动用 savepoint
MySQL 8.0+、PostgreSQL 原生支持 SAVEPOINT，ThinkPHP 没封装该能力，但可通过原生 SQL + Db::execute() 手动介入。关键不是“开启事务”，而是“在已有事务中设回滚点”。
使用场景：支付扣款成功后发优惠券，发券失败需只回滚发券部分，不影响扣款
立即学习“PHP免费学习笔记（深入）”；
- 外层先调用
Db::startTrans()启动事务 - 执行扣款逻辑
- 执行
Db::execute('SAVEPOINT coupon_issue') - 尝试发券；若失败，执行
Db::execute('ROLLBACK TO SAVEPOINT coupon_issue')，而非rollback() - 最后统一
commit()或外层rollback()
注意：SQLite 支持 SAVEPOINT，但旧版 MySQL（ROLLBACK TO，无名称），此时只能靠业务层标记 + 条件跳过后续操作。
Transaction::transaction() 无法替代嵌套，但适合简化单层结构
ThinkPHP 提供的静态方法 Db::transaction() 是语法糖，本质仍是单事务包裹。它会在闭包抛异常时自动 rollback()，正常结束时 commit()。但它和 startTrans() 互斥——不能在外层 transaction() 里再调用内层 transaction()，否则会报错 “There is no active transaction” 或静默失效。
- 适用于“一段完整、不可拆分”的操作，比如用户注册 + 初始化配置
- 不适合需要局部回滚的复合流程（如订单创建 + 库存锁定 + 通知发送，其中通知失败不应影响前两者）
- 若强行嵌套，第二次
transaction()会尝试开启新事务，而 PDO 默认不允许嵌套，直接抛出PDOException
生产环境建议：放弃“嵌套事务”概念，改用补偿事务或状态机
真正可靠的分布式或复合操作，不依赖数据库事务嵌套。ThinkPHP 层面硬搞 SAVEPOINT 容易遗漏异常分支、难以测试、兼容性差（尤其跨数据库）。
- 把长流程拆成幂等步骤，每步落库记录状态（如
order_status字段） - 失败时触发补偿逻辑（如扣款成功但发券失败，则异步补发或退款）
- 用消息队列解耦后续操作，避免事务内执行 HTTP 请求等高风险动作
如果只是想让多个模型方法“看起来能独立回滚”，最务实的做法是：统一由最上层服务方法管理事务，把可能失败的环节提前校验或降级处理，而不是寄希望于框架模拟嵌套。
