Go事务中tx.Rollback()必须检查返回值，因其可能因网络中断、连接关闭等返回非nil错误，忽略会导致状态误判；Commit和Rollback均需显式错误处理，避免defer无条件回滚，正确使用errors.Is(err, sql.ErrNoRows)判断空查询，事务函数宜用goto统一错误出口，所有DB操作须用Context版本以防超时卡死。
Go 事务中 tx.Rollback() 必须检查返回值
很多人以为 tx.Rollback() 只是“尽力而为”，失败了也无所谓——这是最危险的错觉。它可能因网络中断、连接已关闭或底层驱动 bug 而返回非 nil 错误，但如果你忽略它，就等于把事务异常状态当成了成功回滚，后续还可能复用该 *sql.Tx 对象（导致 panic）或误判业务逻辑。
正确做法是：无论 tx.Commit() 还是 tx.Rollback()，都必须显式检查错误，并且 Rollback() 的错误不能简单吞掉。
- 如果
tx.Commit()失败，通常要立即tx.Rollback()；但此时若Rollback()也失败，说明事务状态已不可信，应记录日志并拒绝后续操作 - 不要在 defer 中无条件调用
tx.Rollback()，除非你确保此时tx一定未提交且仍有效（比如刚Begin()就出错） -
Rollback()在事务已提交后调用会返回sql.ErrTxDone，这不是 bug，而是预期行为，需区分处理
用 errors.Is(err, sql.ErrNoRows) 判断查询为空，别用 == nil
事务里执行 QueryRow().Scan() 时，查不到数据会返回 sql.ErrNoRows，但它不是业务错误，而是控制流信号。直接和 nil 比较会掩盖真正的问题，比如数据库连接断开、字段类型不匹配等也会返回非 nil 错误，但语义完全不同。
Go 1.13+ 推荐用 errors.Is() 显式识别这类哨兵错误，避免误把数据库故障当成“没查到”。
立即学习“go语言免费学习笔记（深入）”；
-
errors.Is(err, sql.ErrNoRows)是安全判断“查无结果”的唯一方式 - 如果业务上“查不到 = 错误”，那就按需包装新错误；如果“查不到 = 正常分支”，就只处理
ErrNoRows，其余 err 必须向上抛或记录 - 注意：某些驱动（如 pgx）可能返回自定义错误类型，但只要实现了
Unwrap()并包裹了sql.ErrNoRows，errors.Is()依然有效
事务函数里别提前 return，用 goto 或闭包统一收口
一个典型事务函数往往包含多个 DB 操作、条件分支、资源清理逻辑。如果每个地方都写 if err != nil { tx.Rollback(); return err }，不仅重复，还容易漏掉某处没 rollback，或者 rollback 后又 commit（panic）。
更可控的方式是让错误路径集中到一个出口，保证 rollback 和 error 返回原子发生。
- 用
goto rollback是 Go 标准库和成熟项目（如database/sql自身）常用手法，清晰且零分配 - 也可以用匿名函数包裹事务体，用
defer做 rollback，但要注意：defer 在函数 return 后才执行，无法捕获 panic，且 error 变量作用域易出错 - 避免在事务函数里调用另一个事务函数——嵌套事务在多数数据库（如 MySQL）不真正支持，实际是 savepoint 模拟，但 Go 的
*sql.Tx不提供 savepoint API，强行嵌套极易混乱
context.Context 要传进 db.QueryContext()，别只传给业务逻辑
事务超时、用户取消、服务优雅下线，这些都靠 context.Context 传递信号。但如果只在业务层用 context 控制流程，而 DB 操作仍用无 context 版本（如 Query()），那数据库连接可能卡死在慢查询里，事务长时间挂起，连接池耗尽。
所有带 I/O 的 DB 方法都有 Context 版本，必须用它们，否则 context 就是摆设。
- 用
tx.QueryRowContext(ctx, ...)替代tx.QueryRow(...) - context 超时触发时，底层驱动会尝试中断连接（取决于驱动实现，如
mysql驱动支持readTimeout，pgx支持 cancel request） - 注意：MySQL 的
SET SESSION wait_timeout和 context timeout 是两回事，前者是连接空闲超时，后者是单次查询上限，两者都要设，且 context timeout 应略小于数据库侧 timeout
