不能一概而论：GORM不实现隔离逻辑，幻读能否防止取决于数据库类型（MySQL靠间隙锁仅对当前读生效，PostgreSQL的REPEATABLE READ等价SERIALIZABLE但需重试）、隔离级别设置及查询方式（如是否加FOR UPDATE），且db.Transaction()默认不指定隔离级别，需显式通过Session+sql.TxOptions配置。
幻读在GORM里到底能不能靠隔离级别解决
不能一概而论。GORM本身不实现隔离逻辑，它只是把事务控制权交还给底层数据库；而是否能防止幻读，取决于你用的数据库类型 + 实际设置的隔离级别 + 查询方式。
比如在MySQL中，REPEATABLE READ（默认）仍可能发生幻读——不是因为GORM没做对，而是InnoDB用“间隙锁（Gap Lock）”来缓解，但仅对当前读（如SELECT ... FOR UPDATE或SELECT ... LOCK IN SHARE MODE）生效；普通SELECT语句不加锁，就可能看到新插入的行。
PostgreSQL则不同：它的REPEATABLE READ实际行为等价于串行化（SERIALIZABLE），靠的是快照隔离+冲突检测，能真正避免幻读；但它不支持READ UNCOMMITTED，且REPEATABLE READ下仍可能触发序列化失败错误（SQLSTATE 40001），需要重试逻辑。
GORM中显式启用可防止幻读的查询模式
如果你确认数据库支持、且业务能接受更强的锁或重试机制，GORM提供了几种可落地的写法：
- 对关键查询加锁：用
Session(&gorm.Session{PrepareStmt: true})配合SELECT ... FOR UPDATE，例如db.Clauses(clause.Locking{Strength: "UPDATE"}).Where("status = ?", "pending").Find(&orders) - 手动开启高隔离事务：调用
db.Session(&gorm.Session{NewDB: true}).Begin(&sql.TxOptions{Isolation: sql.LevelSerializable})，注意PostgreSQL会强制升级为SERIALIZABLE，MySQL 8.0+也支持但性能代价大 - 避免“范围条件+无锁读”组合：比如
WHERE created_at > ?这种查询，在READ COMMITTED下极易出现幻读，应搭配FOR UPDATE或改用时间戳+唯一约束做幂等控制
为什么db.Transaction()默认不防幻读
因为GORM的Transaction()方法只封装了Begin()/Commit()/Rollback()，不干预事务启动时的隔离级别参数。它默认复用连接池里已建立的连接，而该连接的隔离级别由数据库驱动初始化时决定（通常是数据库全局默认值）。
常见误区是以为“用了事务就自动可重复读”，其实：
- MySQL连接默认是
REPEATABLE READ，但幻读仍存在（尤其INSERT未被锁住的间隙） - PostgreSQL连接默认是
READ COMMITTED，连不可重复读都防不住，更别说幻读 - GORM没有提供类似
WithIsolationLevel()这样的链式方法（v2/v3均无），必须通过Session+sql.TxOptions显式传入
真正管用的防御策略往往不在GORM层
与其强依赖隔离级别，不如结合业务逻辑做更稳健的设计：
- 用唯一索引替代“查是否存在再插入”的逻辑，让数据库直接报
duplicate key而不是靠事务锁住范围 - 对列表类查询（如分页获取待处理订单），改用基于游标的分页（
WHERE id > ? ORDER BY id LIMIT N），避免条件范围漂移 - 写偏斜（Write Skew）这类更隐蔽的问题，即使设成
SERIALIZABLE也可能漏掉，得靠应用层校验或使用SELECT FOR UPDATE锁定所有相关行
最常被忽略的一点：开发环境用SQLite测试，生产切MySQL/PostgreSQL，而SQLite的事务模型和锁机制完全不同——本地测不出的幻读，上线后第一波并发就暴露。
