Go微服务context超时控制与goroutine泄漏排查全流程

context超时控制：Go微服务的生命线

在Go微服务架构中，context.Context是贯穿请求全链路的核心机制。每一个RPC调用、数据库查询、外部HTTP请求都应该接受context参数，以实现超时控制、取消传播和值传递。然而生产环境中，context使用不当导致的超时失效、goroutine泄漏、级联阻塞等问题屡见不鲜，排查成本极高。

后端开发中，context超时控制不是可选项，而是微服务可用性的基础保障。

context超时传播的正确姿势

超时传播的核心原则：父context取消时，所有子context必须级联取消。

// 错误示例：断开超时传播
func handler(ctx context.Context) {
    // 使用context.Background()创建新的context
    // 父context超时不会传播到这里
    newCtx := context.Background()
    result, err := db.Query(newCtx, sql)
    // handler的ctx超时，db.Query不会被取消，goroutine泄漏
}

// 正确示例：保持传播链
func handler(ctx context.Context) {
    // 基于父context创建子context，超时会级联传播
    childCtx, cancel := context.WithTimeout(ctx, 5*time.Second)
    defer cancel() // 必须调用cancel释放资源
    result, err := db.Query(childCtx, sql)
}

关键要点：永远不要用context.Background()替代请求context。Background()创建的context没有超时、没有取消信号，会在父请求已结束的情况下继续占用资源。

三层超时体系设计

生产级微服务需要构建三层超时防护：

func ProcessOrder(ctx context.Context, order Order) error {
    // 第1层：入口层超时（API网关或HTTP Server设置）
    // 由调用方控制，例如HTTP客户端设置30秒超时
    
    // 第2层：业务层超时
    bizCtx, bizCancel := context.WithTimeout(ctx, 10*time.Second)
    defer bizCancel()
    
    // 第3层：基础设施层超时（更短，给业务逻辑留余量）
    dbCtx, dbCancel := context.WithTimeout(bizCtx, 3*time.Second)
    defer dbCancel()
    
    // 查询数据库
    product, err := productRepo.GetByID(dbCtx, order.ProductID)
    if err != nil {
        return fmt.Errorf("query product: %w", err)
    }
    
    // 调用下游服务（独立超时控制）
    rpcCtx, rpcCancel := context.WithTimeout(bizCtx, 2*time.Second)
    defer rpcCancel()
    err = inventoryClient.Reserve(rpcCtx, product.ID, order.Quantity)
    if err != nil {
        return fmt.Errorf("reserve inventory: %w", err)
    }
    
    return nil
}

三层超时的关系：入口超时 > 业务超时 > 基础设施超时。每一层留出足够余量，避免底层超时导致上层也超时的雪崩效应。

goroutine泄漏的四种典型模式

context使用不当是goroutine泄漏的首要原因。四种典型泄漏模式：

模式1：缺少context取消监听。goroutine内部有长循环，不检查ctx.Done()。

// 泄漏代码
func leakyWorker(ctx context.Context) {
    go func() {
        for {
            doSomeWork()  // 永远不会退出
        }
    }()
}

// 修复：检查context
func fixedWorker(ctx context.Context) {
    go func() {
        for {
            select {
            case <-ctx.Done():
                return // context取消时退出
            default:
                doSomeWork()
            }
        }
    }()
}

模式2：select中缺少ctx.Done()分支。goroutine在channel上永久阻塞。

// 泄漏代码：result channel永远不会收到数据时永久阻塞
func fetchData(ctx context.Context) ([]byte, error) {
    ch := make(chan []byte)
    go func() { ch <- expensiveCall() }()
    return <-ch, nil  // expensiveCall()不返回则goroutine泄漏
}

// 修复：增加context取消分支
func fetchData(ctx context.Context) ([]byte, error) {
    ch := make(chan []byte, 1) // 缓冲channel避免发送方阻塞
    go func() { ch <- expensiveCall() }()
    
    select {
    case data := <-ch:
        return data, nil
    case <-ctx.Done():
        return nil, ctx.Err()  // 超时或取消时退出
    }
}

模式3：HTTP请求body未读取完毕就关闭。连接无法复用，连接池耗尽。

// 修复：超时时排空body
func callAPI(ctx context.Context, url string) ([]byte, error) {
    resp, err := http.NewRequestWithContext(ctx, "GET", url, nil)
    if err != nil {
        return nil, err
    }
    defer func() {
        io.Copy(io.Discard, resp.Body) // 排空body
        resp.Body.Close()
    }()
    return io.ReadAll(io.LimitReader(resp.Body, 1<<20))
}

模式4：Timer未Stop。time.After在select循环中每次创建新Timer，旧Timer不会被GC直到触发。

// 泄漏代码：每次循环创建新Timer
for {
    select {
    case <-ctx.Done():
        return
    case <-time.After(5 * time.Second):  // 每次创建新Timer
        doWork()
    }
}

// 修复：使用time.NewTimer复用
timer := time.NewTimer(5 * time.Second)
defer timer.Stop()
for {
    select {
    case <-ctx.Done():
        return
    case <-timer.C:
        doWork()
        timer.Reset(5 * time.Second)
    }
}

goroutine泄漏排查工具链

当线上出现goroutine数量持续增长时，按以下步骤排查：

1. pprof goroutine profile：访问 /debug/pprof/goroutine?debug=2，查看每个goroutine的栈回溯，定位阻塞位置。

2. runtime.NumGoroutine()：在metrics中暴露goroutine数量，配置告警阈值（例如超过1000告警）。

3. goleak测试：在单元测试中使用 go.uber.org/goleak 检测泄漏，在TestMain中添加 defer goleak.VerifyNone(t)。

4. 链路追踪：在Jaeger/Zipkin中观察span耗时，超时未返回的span对应泄漏的goroutine。