2. Go 语言并发基础回顾：goroutine、channel、sync.WaitGroup 在支付场景中的应用

在支付中间件中，高并发、低延迟与数据一致性是核心挑战。Go 语言的原生并发模型——goroutine、channel 与 sync.WaitGroup——是构建可靠事务边界的基石。本章从支付场景出发，回顾这三者的核心用法与常见陷阱。

2.1 goroutine：支付任务的轻量级执行单元

goroutine 是 Go 运行时管理的轻量级线程，栈初始仅几 KB，可动态伸缩。在支付系统中，每个独立的操作（如风控校验、账户扣减、通知发送）都可以封装为一个 goroutine，实现并行处理。

支付场景示例： 一笔订单支付成功后，需要同时执行：更新订单状态、扣减用户余额、增加商户账户余额、发送支付成功通知。这四个任务无严格先后依赖，可并发执行。 
// 模拟支付后并发处理多个子任务
func handlePaymentSuccess(orderID string) {
    go updateOrderStatus(orderID)
    go deductUserBalance(orderID)
    go addMerchantBalance(orderID)
    go sendNotification(orderID)
    // 问题：主 goroutine 不会等待这些任务完成
}
常见陷阱： 上例中主函数直接返回，四个 goroutine 可能尚未执行完毕。在支付场景中，这会导致订单状态未更新、余额未扣减等严重问题。必须使用同步机制确保所有子任务完成。

2.2 sync.WaitGroup：等待支付子任务全部完成

sync.WaitGroup 用于等待一组 goroutine 结束。在支付中间件中，常用于“扇出-等待”模式：主流程派发多个并发子任务，然后等待全部完成后再进入下一阶段。

方法 作用 支付场景说明
Add(delta int) 增加等待计数器 在启动每个子任务前调用，表示需要等待的任务数
Done() 计数器减 1 每个子任务完成时调用，通常通过 defer wg.Done() 保证
Wait() 阻塞直到计数器归零 主流程在此等待所有支付子任务完成 
func handlePaymentSuccessWithWait(orderID string) {
    var wg sync.WaitGroup

    // 启动 4 个子任务，计数器加 4
    wg.Add(4)

    go func() {
        defer wg.Done()
        updateOrderStatus(orderID)
    }()
    go func() {
        defer wg.Done()
        deductUserBalance(orderID)
    }()
    go func() {
        defer wg.Done()
        addMerchantBalance(orderID)
    }()
    go func() {
        defer wg.Done()
        sendNotification(orderID)
    }()

    // 等待所有子任务完成
    wg.Wait()
    // 此时可以安全地返回支付成功响应
}
最佳实践： 始终在 goroutine 内部使用 defer wg.Done()，即使函数发生 panic 也能保证计数器正确递减，避免主流程永久阻塞。

2.3 channel：支付数据流的管道与信号传递

channel 是 goroutine 之间通信的桥梁。在支付场景中，channel 常用于：

  • 任务分发： 将待处理的支付请求通过 channel 发送给多个工作 goroutine。
  • 结果收集： 子任务将处理结果（成功/失败、错误信息）通过 channel 返回给主流程。
  • 超时控制： 结合 select 和 time.After 实现支付操作的超时取消。
// 使用 channel 收集并发子任务的执行结果
type taskResult struct {
    taskName string
    err      error
}

func handlePaymentWithChannel(orderID string) error {
    resultCh := make(chan taskResult, 4) // 缓冲 channel，避免阻塞
    var wg sync.WaitGroup

    tasks := []func(string) error{
        updateOrderStatus,
        deductUserBalance,
        addMerchantBalance,
        sendNotification,
    }

    for _, task := range tasks {
        wg.Add(1)
        go func(fn func(string) error) {
            defer wg.Done()
            err := fn(orderID)
            resultCh <- taskResult{taskName: "task", err: err}
        }(task)
    }

    // 等待所有任务完成，然后关闭结果 channel
    go func() {
        wg.Wait()
        close(resultCh)
    }()

    // 收集结果，检查是否有错误
    for result := range resultCh {
        if result.err != nil {
            return fmt.Errorf("支付子任务失败: %w", result.err)
        }
    }
    return nil
}
注意： 上例中 taskName 字段未正确赋值，实际生产代码应传递任务名称用于日志追踪。此外，如果某个子任务返回错误，应触发补偿事务（后续章节详述），而非简单返回错误。

2.4 支付并发模型对比：goroutine + WaitGroup vs. goroutine + channel

模式 适用场景 优点 缺点
goroutine + WaitGroup 只关心所有任务是否完成，不关心中间结果 简单直接，代码可读性高 无法获取每个任务的中间状态或部分结果
goroutine + channel 需要收集每个任务的返回值、错误信息或进度 灵活，支持结果聚合、超时、取消 需要额外管理 channel 的关闭与缓冲大小
goroutine + WaitGroup + channel 支付中间件中最常用：既要等待完成，又要收集结果 兼顾同步等待与结果收集 代码稍复杂，需注意 channel 死锁

2.5 支付并发流程架构图

下图展示了一个典型的支付成功处理流程，使用 goroutine + WaitGroup + channel 实现并发子任务与结果收集：

支付成功并发处理流程（goroutine + WaitGroup + channel） 支付成功入口 扇出 4 个子任务 更新订单状态 扣减用户余额 增加商户余额 发送通知 wg.Done() wg.Done() wg.Done() wg.Done() 结果 channel（缓冲 4） wg.Wait() + 遍历 channel

2.6 支付场景中的并发陷阱与避坑指南

  • goroutine 泄漏： 启动的 goroutine 如果阻塞在 channel 发送/接收上且没有正确关闭，会导致内存泄漏。支付服务长期运行，泄漏会逐渐耗尽资源。
  • WaitGroup 计数器负数： Add 调用次数少于 Done 调用次数会导致 panic。务必在启动 goroutine 前调用 Add，并在 goroutine 内使用 defer wg.Done()。
  • channel 死锁： 无缓冲 channel 在发送和接收未配对时会永久阻塞。支付场景中推荐使用带缓冲的 channel，并确保在合适的时机 close。
  • 共享变量竞争： 多个 goroutine 同时读写同一变量（如全局计数器、账户余额）会导致数据竞争。使用 sync.Mutex 或原子操作保护临界区。
← 上一章 📖 返回目录 下一章 →