Golang on 认真的雪

GORM 事务中的隐藏陷阱：return nil 不代表没事发生

Thu, 28 May 2026 10:07:03 +0800

背景

在 Go + GORM 的日常开发中，事务写法通常如下：

err := db.Transaction(func(tx *gorm.DB) error {
 // 业务逻辑
 if err := tx.Create(&user).Error; err != nil {
 return err // 回滚
 }
 // 更多操作...
 return nil // 提交
})

这个模型很直觉：返回 nil → 提交事务，返回 error → 回滚事务。

但最近踩了一个坑：在事务内吞掉了错误并返回 nil，GORM 却报了 commit unexpectedly resulted in rollback。

问题复现

简化后的伪代码如下：

err := db.Transaction(func(tx *gorm.DB) error {
 // 第一条 SQL：创建记录
 if err := tx.Create(&recordA).Error; err != nil {
 if errors.Is(err, gorm.ErrDuplicatedKey) {
 // 唯一键冲突，认为是可以接受的，跳过
 return nil // ← 问题出在这里
 }
 return err
 }

 // 第二条 SQL：创建另一条记录
 if err := tx.Create(&recordB).Error; err != nil {
 return err
 }

 return nil
})

预期行为：遇到重复键冲突时，跳过并提交事务。

实际行为：

ERROR: commit unexpectedly resulted in rollback

事务直接失败，err 不为 nil。

根因分析

关键在于 GORM（以及底层的数据库驱动）的事务状态机：

SQL 执行报错时，数据库驱动会将事务标记为 aborted 状态。 PostgreSQL 等数据库在遇到约束违反（如唯一键冲突）后，当前事务即进入 aborted 状态，后续所有操作都会被拒绝，直到执行 ROLLBACK。
GORM 的 Transaction() 方法看到你返回 nil，就会尝试 COMMIT。
但 COMMIT 一个已经 aborted 的事务，数据库会返回错误——因为事务已经被隐式回滚了，无法提交。

时序如下：

tx.Create(&recordA) → 唯一键冲突，PostgreSQL 标记事务为 aborted
return nil → GORM 尝试 COMMIT
COMMIT → 数据库拒绝：事务已经是 aborted 状态
 → GORM 收到错误，报 "commit unexpectedly resulted in rollback"

核心问题：你吞掉了错误，但事务状态并没有"恢复原状"。数据库驱动已经记住了这个错误。

解决方案

思路：把"可预期的冲突"包装成一个特殊的错误类型，在事务外处理

第一步：定义业务错误类型

// ErrDuplicated 重复键冲突的业务错误
var ErrDuplicated = errors.New("record already exists")

第二步：事务内返回该错误，而不是 return nil

err := db.Transaction(func(tx *gorm.DB) error {
 if err := tx.Create(&recordA).Error; err != nil {
 if errors.Is(err, gorm.ErrDuplicatedKey) {
 return ErrDuplicated // ← 返回业务错误，让事务正常回滚
 }
 return err
 }

 if err := tx.Create(&recordB).Error; err != nil {
 return err
 }

 return nil
})

第三步：在事务外部区分处理

if err != nil {
 if errors.Is(err, ErrDuplicated) {
 // 重复键冲突是可预期的，正常处理
 log.Println("记录已存在，跳过")
 return nil
 }
 // 其他错误正常上报
 return err
}

为什么这样是对的？

事务内部：任何错误都如实返回，让 GORM 执行 ROLLBACK，保持事务状态干净。
事务外部：通过错误类型区分"业务可接受的冲突"和"真正的失败"。
不会触碰数据库事务状态机的"禁区"。

总结

做法	结果
事务内吞掉 DB 错误，返回 `nil`	事务状态已 aborted，COMMIT 必然失败
事务内返回自定义错误，外部判断处理	事务正常 ROLLBACK，业务逻辑正确分流

记住：GORM 事务中，return nil 永远意味着"请提交"。如果你不能提交，就不要返回 nil。

即使某个错误在业务上是"可以接受的"，也要在事务外部去接受它，而不是在事务内部悄悄吞掉它。

golang go常用命令

Thu, 24 Apr 2025 16:29:00 +0800

查看某个包的所有版本

go list -m -versions <pkg> go list -m -versions github.com/go-kratos/kratos/v2

查看某个二进制的构建信息

go version -m <path> go version -m /usr/bin/go/bin/go

使用 File Watcher 和 goimports-reviser 自动格式化 Golang 代码

Sat, 28 Oct 2023 15:51:00 +0800

goimports-reviser 是一个管理 import 分组的工具，当前也已支持（ gofmt ）格式化代码。github 地址 [https://github.com/incu6us/goimports-reviser][https_github.com_incu6us_goimports-reviser]

这里来

安装 goimports-reviser

go install -v github.com/incu6us/goimports-reviser/v3@latest

设置 File Watcher

Goland 打开 ***文件 →设置 → 工具→File Watcher ***

新增一个自定义，参数如下

配置项	值	说明
文件类型	Go文件
作用域	当前文件
程序	goimports-reviser	goimports-reviser 可执行程序路径
实参	-rm-unused -format -use-cache -company-prefixes=git.test.com $FilePath$	这里没有加 -set-alias ，根据个人需求，prefixes是私有库地址
要刷新的输出路径	$FileName$	这个一定要加，不然会容易出现 “文件缓存冲突”
自动保存编辑的文件以触发观察程序	false	取消勾选，否则容易出现还没编辑完成就被格式化了

如图所示

取消保存时的操作

Goland保存时会默认重新格式化代码和*优化 import ，*因为 goimports-reviser 会帮我们做 goimports 和 gofmt 操作，我们保存时没必要再重新执行这些功能。这个根据个人情况修改

Goland 打开 ***文件 →******设置 → 工具→保存时的操作，***取消勾选 重新格式化代码、优化 import

如图所示

nginx 代理 golang，禁止访问目录的办法

Thu, 16 Jul 2020 19:03:50 +0800

项目是用golang作为服务器，nginx负责反向代理。

但是现在有一个问题，golang的web服务器，目录浏览不能自定义关闭。

最初是想nginx代理静态文件，然后后台请求反向代理到golang，但是这样有更新每次都要git pull两次，有点麻烦。最后还是选择向nginx下手。目录浏览的路径最后肯定是 / ,然后除去根目录，其它文件夹肯定是/xxx/这样的，直接一个通配符就好了。

location ~ (/.*/)${ return 404;}

目前够用了。