当前位置：首页 > 文章列表 > Golang > Go问答 > Go 回调接口为什么不该统一返回 error：同步确认、异步投递与错误所有权

Go 回调接口为什么不该统一返回 error：同步确认、异步投递与错误所有权

来源：17golang原创 2026-08-11 13:00:43 0浏览收藏

订单状态从“待支付”变成“已支付”时，业务代码往往会顺手挂一个回调：校验库存、写审计日志、通知下游。最初把所有回调都定义成 func(Event) error 很省事，几周后却会出现一个难排的误判：同步校验返回的错误必须阻断订单，后台通知返回的错误却只能进入重试队列，两个调用方看着同一个签名，却拥有完全不同的责任。

要点速览

回调是否返回 error，先看调用方是否需要在当前请求内做决定。
同步确认应把失败返回给上层；异步投递应返回“已接收/未接收”，不要伪装成业务执行结果。
后台任务的错误由任务系统负责记录、重试和告警，不能让提交方替它背锅。
接口拆分的核心不是少写一个 error，而是把错误所有权放回真正能处理它的组件。

先看调用关系：谁拥有这次错误

判断一个回调要不要返回 error，可以先问一句：这个错误发生后，当前调用方还能不能改变结果？如果答案是“能”，它就是同步确认；如果只能把事件交给另一个执行单元，返回值表达的应是接收状态，而不是最终业务结果。

下面这个最小事件模型故意保留两种调用关系。Validator 参与订单提交决策，Publisher 只负责把事件交给队列：

type OrderPaid struct {
    OrderID string
    Amount  int64
}

type Validator interface {
    Validate(context.Context, OrderPaid) error
}

type Publisher interface {
    Publish(context.Context, OrderPaid) (Receipt, error)
}

type Receipt struct {
    Accepted bool
    Message  string
}

Validate 的错误可以直接转成支付流程的失败原因；Publish 的返回值只说明消息有没有被当前组件接收。即使消息已经接收，消费者仍可能在几秒后因为下游不可用而失败。

统一返回 error，最容易制造哪种误判

问题通常不在接口声明本身，而在调用者把所有错误都当成同一种错误。比如下面的代码把通知投递失败当成订单支付失败：

func Pay(ctx context.Context, p Publisher, event OrderPaid) error {
    if err := p.Publish(ctx, event); err != nil {
        return fmt.Errorf("支付失败: %w", err)
    }
    return nil
}

如果 Publish 只是把消息写入本地缓冲区，那么返回的错误最多表示“这次交接没有完成”。它不应该让支付接口回滚一个已经完成的扣款；正确动作可能是标记“待通知”，交给投递任务重试。

相反，库存预占属于同步确认。库存组件返回 ErrOutOfStock 时，订单仍处在可改变的窗口内，支付流程就应该停止后续动作，并把这个业务结果反馈给调用方。把这两类回调合并成一个接口，调用方只能靠注释猜测错误含义。

把接口拆成两条，调用方才不会误判

接口拆分不是为了追求更多类型，而是让返回值和时间边界对齐。同步路径表达“这次操作是否通过”，异步路径表达“消息是否已交接”：

type OrderRules interface {
    Validate(context.Context, OrderPaid) error
}

type OrderEvents interface {
    Enqueue(context.Context, OrderPaid) (Receipt, error)
}

func CompletePayment(ctx context.Context, rules OrderRules, events OrderEvents, e OrderPaid) error {
    if err := rules.Validate(ctx, e); err != nil {
        return err
    }

    receipt, err := events.Enqueue(ctx, e)
    if err != nil {
        return fmt.Errorf("事件未交接: %w", err)
    }
    if !receipt.Accepted {
        return fmt.Errorf("事件未接收: %s", receipt.Message)
    }
    return nil
}

这里仍然有 error，但它的含义变了：只表示队列不可用、上下文取消或消息没有被接收，不表示消费者已经完成审计。审计任务的执行错误应该出现在任务日志、重试次数和死信记录里。