Go database/sql Tx区分可重试冲突与业务错误的处理边界

Go database/sql 不会替应用判断“这个事务错误能不能重试”。更稳妥的边界是：事务内部只完成一轮读写并负责回滚，仓储层把数据库驱动的冲突码映射为稳定的 ErrConflict，业务校验错误保持原样；真正的重试放在事务函数外，并且只重试明确可重试的冲突。

这篇示例使用一个“扣减库存并创建订单”的小场景。代码中的数据库驱动错误码只是映射示意，生产环境必须根据实际数据库和驱动文档确认，不要把所有 error 都当成冲突。

先定义两类错误的判定边界

业务错误通常是库存不足、订单状态不允许变更、参数不满足规则。这类错误即使再次执行也不会自动变好，应该直接返回。可重试冲突则是并发事务之间的短暂竞争，例如序列化冲突或死锁；它们需要由数据库驱动暴露原始错误，再由仓储层集中转换。

package order

import "errors"

// ErrConflict 只代表已经确认可以由上层有限重试的并发冲突。
var ErrConflict = errors.New("transaction conflict")

// ErrInsufficientStock 是业务拒绝，不应进入重试循环。
var ErrInsufficientStock = errors.New("insufficient stock")

// stateCoder 让仓储层读取驱动提供的 SQL 状态码；不同驱动需单独适配。
type stateCoder interface {
	SQLState() string
}

func isRetryableConflict(err error) bool {
	var coded stateCoder
	if !errors.As(err, &coded) {
		return false
	}
	// 40001、40P01 仅作常见示例，实际映射以数据库和驱动为准。
	switch coded.SQLState() {
	case "40001", "40P01":
		return true
	default:
		return false
	}
}

这里用 errors.Is 和 errors.As 保留包装错误的可判定性。不要用 strings.Contains(err.Error(), "deadlock") 做生产判断：语言、驱动版本和数据库配置都可能改变错误文本。

让一次事务只负责一轮读写

事务函数不要自己循环重试。它只接收一次调用，创建 Tx，完成库存检查和扣减，再插入订单。任何执行失败都回滚；提交失败也要把原始错误交给外层判断。这样可以避免在已经结束的事务上继续使用 Tx。

func (r *Repo) createOrderOnce(ctx context.Context, userID, sku string, qty int) error {
	tx, err := r.db.BeginTx(ctx, nil)
	if err != nil {
		return err
	}
	defer func() {
		// Commit 成功后 Rollback 没有副作用；失败路径由它兜底收尾。
		_ = tx.Rollback()
	}()

	var stock int
	err = tx.QueryRowContext(ctx,
		"SELECT stock FROM inventory WHERE sku = ? FOR UPDATE", sku,
	).Scan(&stock)
	if err != nil {
		return err
	}
	if stock 

示例省略了 Repo 定义及驱动注册代码，重点是责任边界。为了让代码可读，还需要在文件导入区加入 context、database/sql 和 fmt。查询占位符也要按实际驱动调整。

在事务外只重试明确的冲突

外层重试要有上限、退避和上下文取消。业务错误直接返回，未知错误也不要擅自重试。特别要注意提交阶段的连接断开：客户端可能不知道提交是否已经在数据库生效，这时不能简单当作“未执行”再创建一笔订单，应使用业务幂等键查询最终状态。

func (r *Repo) CreateOrder(ctx context.Context, userID, sku string, qty int) error {
	const maxAttempts = 3
	for attempt := 1; attempt 

重试函数假设“创建订单”有唯一业务幂等键，或者库存扣减和订单写入能被同一事务完整保护。没有这个前提时，重试次数越多，重复副作用的风险越高。

发布前检查重试与事务边界

最终可以记住一句话：database/sql 负责事务生命周期，仓储层负责把驱动错误变成业务可识别的类型，服务层负责决定是否有限重试。三层职责分开后，业务错误不会被无意义地重复执行，真正的并发冲突也有清晰的恢复路径。

常见问题

Go database/sql 会自动告诉我哪些错误能重试吗？

不会。database/sql 提供通用接口，具体错误形态由数据库驱动决定。应用需要针对实际数据库和驱动做小范围错误码适配。

事务提交返回错误时可以马上再执行一次吗？

不能一概而论。提交阶段断连可能代表结果未知，先用幂等键或业务状态查询确认，再决定是否补偿或重试。