事务中调用Create()后user.ID可直接读取，因GORM通过sql.Result.LastInsertId()在INSERT后立即获取ID，该操作与事务状态无关；MySQL、TiDB、SQLite驱动均支持，但需主键字段可导出且数据库返回插入ID。
事务中调用 Create() 后，user.ID 仍能直接读取，无需额外查询或 LastInsertId() 调用——前提是主键字段可导出且数据库驱动支持。
为什么事务里也能拿到 ID？
GORM 的 Create() 在底层使用 sql.Result.LastInsertId() 获取自增 ID，这个操作与事务状态无关。只要数据库（如 MySQL、TiDB）在 INSERT 执行后能返回插入 ID（即驱动实现了 Result.LastInsertId 接口），GORM 就会在事务提交前完成赋值。
- MySQL 驱动（
github.com/go-sql-driver/mysql）完全支持该行为 - TiDB 兼容 MySQL 协议，同样支持，但需注意：若用
SEQUENCE替代自增（如NEXT VALUE FOR seq_for_autoid），则必须确保列定义为DEFAULT nextval(...)且 GORM 没跳过该字段 - SQLite 驱动也支持，但仅限单个插入；批量插入时部分驱动可能不返回全部 ID（见下文）
Create() 在事务中是否可靠？
是可靠的，但要注意几个边界条件：
- 必须传入结构体指针，例如
db.Create(&user)，而非db.Create(user)—— 否则user.ID不会被修改 - 主键字段必须可导出（首字母大写），且类型匹配（
int、int64、uint、uint64），否则 GORM 无法写入 - 若用
db.Save(&user)替代Create()，当user.ID != 0时会走 UPDATE，不会生成新 ID - 事务未提交前，其他连接查不到这条记录，但当前事务内
user.ID已就绪，可立即用于外键关联或日志记录
批量插入（Create([]interface{})）时 ID 怎么拿？
批量插入后，每个元素的主键字段也会被原地填充，但有重要限制：
- MySQL 驱动只返回第一个插入 ID 和影响行数（
result.RowsAffected），GORM 依赖此机制推算后续 ID —— 这在自增主键下成立，但在非连续场景（如并发插入、触发器干预）可能不准 - TiDB + SEQUENCE 场景下，
CreateInBatches()更稳妥，因每批独立执行，ID 由数据库逐个生成并返回 - 若需 100% 确保每个 ID 正确，且数据量不大，改用循环单条
Create()更直观 - 示例：
users := []User{{Name: "a"}, {Name: "b"}, {Name: "c"}} db.Create(&users) // users[0].ID, users[1].ID, users[2].ID 均已赋值（假设自增）
容易被忽略的坑
最常踩的是字段标签和驱动兼容性混搭：
-
sql:"-"或gorm:"-"会让字段完全不参与 INSERT，若你把主键标成这样，ID永远是零值 - 用
gorm:"default:0"覆盖了自增逻辑，导致数据库不生成 ID，GORM 也就无从获取 - PostgreSQL 用户注意：
pgx驱动需启用pgx.QueryResult支持，否则LastInsertId()返回 0；推荐显式加RETURNING id（见下） - 如果你用的是 PostgreSQL 或需要绝对可控，可绕过
Create()，改用原生 SQL：db.Raw("INSERT INTO users (name) VALUES (?) RETURNING id", "jinzhu").Scan(&id).Error
事务不是 ID 获取的障碍，真正卡住你的往往是字段导出性、驱动能力、以及对“自增”和“默认值”的混淆。别猜，直接打日志看 user.ID 是否变化，再查 result.Error 是否为空——这是最短验证路径。
