buffalo 的 pop 不支持真正的事务嵌套，所谓“嵌套”只是作用域隔离而非数据库 savepoint；pop.transaction 会复用当前事务对象，内层 rollback 会回滚整个事务，需手动执行 raw sql 实现 savepoint。
Buffalo 的 Pop 不支持真正的事务嵌套，所谓“嵌套”只是作用域隔离，不是数据库层面的 SAVEPOINT。
Pop.Transaction 会覆盖外层事务而不是嵌套
当你在已开启事务的 buffalo.Context 中再次调用 Pop.Transaction，它不会创建新 SAVEPOINT，而是直接复用当前事务对象（*pop.Connection），并把新 handler 包裹进去。这意味着：
- 内层
tx.Rollback()实际会回滚整个事务，影响外层逻辑 - 没有
SAVEPOINT/RELEASE SAVEPOINT语句生成，底层 PostgreSQL/MySQL 不感知“嵌套” - 哪怕你手动传入
tx.WithContext(ctx)，Pop 仍按单事务模型处理
想模拟嵌套行为，得手动用 SAVEPOINT
Pop 原生不封装 SAVEPOINT 操作，必须绕过 Pop.Transaction，直接操作底层 SQL 连接：
- 从
c.Value("tx").(*pop.Connection)取出当前事务连接（需确保已在事务中） - 执行
tx.RawQuery("SAVEPOINT sp_name").Exec() - 出错时用
tx.RawQuery("ROLLBACK TO SAVEPOINT sp_name").Exec() - 成功时可选
tx.RawQuery("RELEASE SAVEPOINT sp_name").Exec()
注意：Pop 的 tx.Store 和 tx.Find 等方法仍走同一连接，自动处于该 SAVEPOINT 范围内。
Buffalo框架 1.0.1 版本源码包下载，适合需要错误处理改进、依赖更新、render.Download 注释和 request logger 调整的 v1 项目。
Buffalo context 里事务生命周期难控制
Buffalo 默认通过 app.Use(pop.Transaction(app.DB)) 注入全局事务中间件，所有请求都带一个事务 —— 但这个事务在 c.Response().Written() 后才自动 Commit 或 Rollback。这导致：
- 你在 handler 里手动
tx.Rollback()后，外层中间件仍可能再 Commit，引发 panic - 无法在 middleware 链中提前终止事务（比如鉴权失败要立即回滚）
- 并发调用多个
Pop.Transactionhandler 时，事务对象被复用，状态混乱
真正可控的做法是：禁用全局事务中间件，改用显式 app.DB.Transaction(func(tx *pop.Connection) error { ... })，并在每个需要隔离的逻辑块里自己管理 SAVEPOINT。
微服务场景下更不该依赖 Pop.Transaction
如果你在 product-service 里调用 order-service，而两者都用了 Pop.Transaction，那它们的事务完全独立、无法协调。Saga 补偿只能靠业务代码写，Pop 不提供跨服务事务上下文透传机制。这时候强行“嵌套”只会掩盖分布式一致性问题。
真实项目里，事务边界必须和业务用例对齐，而不是被框架的 Transaction 函数名误导 —— 它从来就不是 ACID 意义上的嵌套事务。
