Go操作MySQL事务隔离级别必须用db.BeginTx(ctx, &sql.TxOptions{Isolation: level})显式设置，DSN中isolation参数无效；默认继承会话级配置易致脏读/幻读；GORM需绕过封装用原生*sql.Tx控制。
Go 语言操作 MySQL 事务隔离级别，不能靠连接字符串全局设置，必须在 BeginTx 时显式传入 sql.TxOptions；否则默认沿用 MySQL 服务端全局或会话级配置，极易导致并发脏读或幻读。
Go 中设置事务隔离级别必须用 BeginTx + sql.TxOptions
很多人误以为在 DSN 里加 ?isolation=READ-COMMITTED 就能生效，但 database/sql 标准库根本不解析这个参数。MySQL 驱动（go-sql-driver/mysql）也未实现该行为——它只认连接参数如 parseTime、loc，对隔离级别无响应。
真正起作用的只有 db.BeginTx(ctx, &sql.TxOptions{Isolation: sql.LevelReadCommitted})。MySQL 服务端收到的是标准 SQL 的 START TRANSACTION WITH CONSISTENT SNAPSHOT 或 SET TRANSACTION ISOLATION LEVEL ...，由驱动底层拼装发送。
-
sql.LevelReadUncommitted→ 对应 MySQL 的READ UNCOMMITTED，极少见，慎用 -
sql.LevelReadCommitted→ 多数业务首选，避免脏读，但需接受不可重复读 -
sql.LevelRepeatableRead→ MySQL 默认，InnoDB 下可防止脏读和不可重复读，但幻读仍可能（需配合SELECT ... FOR UPDATE） -
sql.LevelSerializable→ 强一致性，但锁粒度大、并发差，线上慎用
为什么 db.Begin() 无法指定隔离级别？
db.Begin() 是 db.BeginTx(ctx, nil) 的简写，第二个参数为 nil，意味着完全继承当前连接的会话隔离级别。而该会话级别可能来自：
立即学习“go语言免费学习笔记（深入）”；
- MySQL 启动配置中的
transaction_isolation（通常是REPEATABLE-READ） - 之前执行过
SET SESSION TRANSACTION ISOLATION LEVEL ...的语句 - 连接池中复用的旧连接残留状态
这就导致：同一段代码在本地开发环境（手动设过 READ-COMMITTED）跑正常，上线后却因连接池混用而回归默认 REPEATABLE-READ，引发幻读问题——尤其在分页查询 + 插入场景下。
GORM 用户注意：Session 和 Transaction 的隔离级别不互通
GORM v2+ 的 Session(&gorm.Session{NewDB: true}) 不影响事务隔离级别；只有显式调用 db.Transaction(func(tx *gorm.DB) error { ... }) 时，内部才用 BeginTx。但 GORM 默认不传 sql.TxOptions，所以它的事务仍是会话级隔离级别。
正确做法是绕过 GORM 的封装，直接拿到原生 *sql.DB：
tx, err := db.DB().BeginTx(ctx, &sql.TxOptions{
Isolation: sql.LevelReadCommitted,
})
if err != nil {
return err
}
defer tx.Rollback()
// 手动用 tx.Query/tx.Exec，或传给 GORM：gormDB = gormDB.Session(&gorm.Session{DryRun: false}).Debug().WithContext(ctx).Session(&gorm.Session{NewDB: true})
// 注意：GORM 不会自动把 tx 绑定进去，需自行适配
更稳妥的方式是彻底放弃 GORM 的事务封装，用原生 *sql.Tx 控制关键路径，仅用 GORM 做单条记录的 CRUD 映射。
并发 goroutine 中事务隔离级别的坑
多个 goroutine 共享同一个 *sql.DB 实例没问题，但每个事务必须独占一个 *sql.Tx。常见错误是：
- 把
tx当成全局变量在多个 goroutine 间传递并复用 → 报错sql: transaction has already been committed or rolled back - 在 goroutine 内部调用
db.Begin()却忘了defer tx.Rollback()→ 连接泄漏，最终触发too many connections - 跨 goroutine 等待同一事务结果（比如用 channel 通知）→ 实际上事务已随 goroutine 结束而隐式关闭
真正安全的做法是：每个 goroutine 自己调用 BeginTx，自己管理生命周期，绝不共享 tx 实例。事务边界必须与 goroutine 边界严格对齐。
隔离级别不是开关，而是与具体 SQL 操作强耦合的契约。比如 SELECT ... FOR UPDATE 在 REPEATABLE-READ 下会加间隙锁，在 READ-COMMITTED 下只加行锁——这意味着你改了隔离级别，很可能得同步调整 SQL 写法和锁策略。
