*sql.Tx 不可跨 goroutine 共享——它是单次数据库会话的有状态上下文，由创建它的 goroutine 独占控制生命周期，多 goroutine 访问会因状态机破坏导致 panic。
*sql.Tx 不可跨 goroutine 共享——它不是连接池句柄，而是单次数据库会话的有状态上下文，一旦在某个 goroutine 中调用 Commit() 或 Rollback()，该事务即终止，其他 goroutine 持有该 *sql.Tx 的引用再调用任何方法都会 panic。
为什么把 *sql.Tx 传给多个 goroutine 会 panic
事务对象 *sql.Tx 内部维护着一个已获取但未归还的底层连接（来自 *sql.DB 连接池），且绑定了一组尚未提交的变更快照。Go 的 database/sql 包明确要求：事务必须由创建它的 goroutine 完整控制生命周期。常见错误现象包括：
panic: sql: transaction has already been committed or rolled backpanic: sql: Transaction is closed- 看似成功执行了
QueryRow()，但后续Commit()却失败或静默丢弃
根本原因不是并发写冲突，而是事务状态机被多个 goroutine 非顺序、非独占地触发，破坏了“begin → exec → commit/rollback”的线性契约。
正确做法：事务逻辑必须收束到单个 goroutine
所有涉及同一 *sql.Tx 的操作（查询、更新、插入、提交）必须在同一个 goroutine 中完成。若业务逻辑天然分散（如异步校验 + 主流程写入），需重构为同步协作模式：
立即学习“go语言免费学习笔记（深入）”；
- 用
channel或sync.WaitGroup等待前置检查 goroutine 完成，再在主 goroutine 中开启并使用事务 - 将校验逻辑内联进事务 goroutine，用
SELECT ... FOR UPDATE等语句在事务内完成一致性检查 - 避免“先查后写”式双阶段操作；改用原子 SQL（如
INSERT ... ON CONFLICT DO UPDATE）减少事务外依赖
示例中错误写法：
tx, _ := db.Begin()
go func() {
tx.QueryRow("SELECT ...") // ⚠️ 不安全：tx 被另一个 goroutine 使用
}()
err := tx.Commit() // 可能 panic 或失效
需要跨 goroutine 协作？用 *sql.DB，别用 *sql.Tx
如果多个 goroutine 确实需要各自独立地读写数据库（比如批量导入、定时清理、事件响应），它们应各自从共享的 *sql.DB 获取自己的 *sql.Tx，而非复用同一个事务实例：
-
*sql.DB是并发安全的，可全局复用 - 每个 goroutine 调用
db.Begin()得到专属*sql.Tx，互不影响 - 注意连接池压力：高并发事务可能耗尽
PoolSize，需合理配置（如PoolSize: 200）
这种模式下，事务隔离靠数据库引擎保证，goroutine 间无共享状态，自然规避了事务对象竞争问题。
容易被忽略的关键点
事务不是“连接”，也不是“句柄”，它是一个有严格生命周期的**一次性会话资源**。即使你确保只有一个 goroutine 写、其他只读，*sql.Tx 也不支持并发读——因为其内部状态（如游标位置、是否已提交）不提供内存可见性同步机制。真正的安全边界只有一条：谁 Begin()，谁负责 Commit()/Rollback()，且全程不移交控制权。
