Go语言Context是后端开发中控制goroutine生命周期和超时行为的标准机制。微服务架构下，一个请求往往串联多个下游调用，若缺乏统一的超时和取消传播，局部延迟会引发goroutine堆积，最终拖垮整个服务。本文梳理Context的使用模式，结合实际Goroutine泄漏场景给出排查和修复方案。

Context的设计哲学与四种派生方式

Context的核心设计是树形派生：每个请求创建一个根Context，下游操作从父Context派生子Context，取消信号沿树向下传播。四种派生函数对应不同场景：

// 1. WithCancel：手动取消，用于需要主动终止的场景
ctx, cancel := context.WithCancel(parent)
defer cancel()

// 2. WithTimeout：超时自动取消，用于下游调用超时控制
ctx, cancel := context.WithTimeout(parent, 5*time.Second)
defer cancel()

// 3. WithDeadline：到指定时间点取消
deadline := time.Now().Add(30 * time.Second)
ctx, cancel := context.WithDeadline(parent, deadline)
defer cancel()

// 4. WithValue：在Context中携带请求范围的键值对
ctx = context.WithValue(parent, "requestID", "req-12345")
// 注意：WithValue不实现取消传播，仅用于传值

使用原则：Context作为函数第一个参数传递，命名统一为ctx；不要将Context存入struct字段；不要传nil Context，用context.Background()或context.TODO()代替。

超时控制与取消传播机制

以一个HTTP服务处理函数为例，展示Context在多层调用链中的传播：

func HandleRequest(w http.ResponseWriter, r *http.Request) {
    // 请求级超时：30秒
    ctx, cancel := context.WithTimeout(r.Context(), 30*time.Second)
    defer cancel()
    
    result, err := fetchUserData(ctx, "user-123")
    if err != nil {
        if ctx.Err() == context.DeadlineExceeded {
            http.Error(w, "请求超时", http.StatusGatewayTimeout)
        } else {
            http.Error(w, err.Error(), http.StatusInternalServerError)
        }
        return
    }
    json.NewEncoder(w).Encode(result)
}

func fetchUserData(ctx context.Context, userID string) (*User, error) {
    // 数据库查询超时：5秒
    dbCtx, cancel := context.WithTimeout(ctx, 5*time.Second)
    defer cancel()
    
    var user User
    err := db.QueryRowContext(dbCtx, 
        "SELECT id, name, email FROM users WHERE id = $1", userID).Scan(
        &user.ID, &user.Name, &user.Email)
    if err != nil {
        return nil, err
    }
    
    // 调用外部API超时：3秒
    apiCtx, cancel := context.WithTimeout(ctx, 3*time.Second)
    defer cancel()
    
    profile, err := callProfileAPI(apiCtx, userID)
    if err != nil {
        return nil, err
    }
    user.Profile = profile
    return &user, nil
}

当30秒根超时触发时，ctx.Done()通道关闭，所有从该Context派生的子Context立即收到取消信号，正在执行的数据库查询和HTTP调用中断。这种传播机制确保一处超时不会导致goroutine无限阻塞。

Goroutine泄漏的常见模式

泄漏的goroutine不会被GC回收，持续占用内存和调度资源。以下是三种典型泄漏场景：

场景一：channel发送阻塞导致泄漏

// 泄漏代码：没有消费者读取ch，goroutine永远阻塞在发送
func leakyFunc() {
    ch := make(chan int)
    go func() {
        result := expensiveComputation()
        ch <- result  // 如果没人接收，这里永远阻塞
    }()
    // 函数返回，ch没有消费者，goroutine泄漏
}

// 修复：使用带缓冲的channel或select+Context
func fixedFunc(ctx context.Context) (int, error) {
    ch := make(chan int, 1)  // 缓冲为1，发送不会阻塞
    go func() {
        result := expensiveComputation()
        select {
        case ch <- result:
        case <-ctx.Done():
            return  // Context取消时退出goroutine
        }
    }()
    
    select {
    case result := <-ch:
        return result, nil
    case <-ctx.Done():
        return 0, ctx.Err()
    }
}

场景二：HTTP客户端未关闭Body

// 泄漏代码：resp.Body未关闭，连接无法复用
func leakyHTTP(url string) ([]byte, error) {
    resp, err := http.Get(url)
    if err != nil {
        return nil, err
    }
    // 忘记defer resp.Body.Close()
    return io.ReadAll(resp.Body)
}

// 修复：始终关闭Body，并传入Context控制超时
func fixedHTTP(ctx context.Context, url string) ([]byte, error) {
    req, err := http.NewRequestWithContext(ctx, "GET", url, nil)
    if err != nil {
        return nil, err
    }
    resp, err := http.DefaultClient.Do(req)
    if err != nil {
        return nil, err
    }
    defer resp.Body.Close()
    return io.ReadAll(resp.Body)
}

pprof排查Goroutine泄漏

Go标准库内置pprof工具，可以快速定位泄漏的goroutine。在服务中启用pprof：

import _ "net/http/pprof"

func main() {
    // 启动pprof服务
    go func() {
        http.ListenAndServe("localhost:6060", nil)
    }()
    
    // 业务逻辑
    http.ListenAndServe(":8080", handler)
}

通过命令行或浏览器查看goroutine信息：

# 查看goroutine数量和调用栈
go tool pprof http://localhost:6060/debug/pprof/goroutine

# pprof交互命令
(pprof) top          # 按goroutine数量排序
(pprof) traces       # 查看完整调用栈

# 或使用curl快速查看
curl http://localhost:6060/debug/pprof/goroutine?debug=1
# 输出示例：
# goroutine 1234 [chan send]:
# main.leakyFunc.func1()
#     /app/main.go:25 +0x8a
# created by main.leakyFunc
#     /app/main.go:23 +0x66

调用栈中[chan send]、[chan receive]、[select]等状态的goroutine数量异常增长，通常指向泄漏点。对比正常负载下的goroutine基线数，Leak时数量会随请求量持续增长不回落。

防御性编程实践

避免Goroutine泄漏的工程规范：

• 每个启动goroutine的地方，必须明确其退出条件，优先使用Context控制生命周期
• channel发送操作用select包裹ctx.Done()，避免无消费者永久阻塞
• HTTP响应体必须defer Close()，使用http.NewRequestWithContext替代http.Get
• 使用errgroup.WithContext管理并发goroutine，任一出错自动取消全部

// errgroup管理并发：任一goroutine出错自动取消其他
import "golang.org/x/sync/errgroup"

func fetchAll(ctx context.Context, urls []string) ([][]byte, error) {
    g, ctx := errgroup.WithContext(ctx)
    results := make([][]byte, len(urls))
    
    for i, url := range urls {
        i, url := i, url  // 避免闭包变量捕获
        g.Go(func() error {
            data, err := fixedHTTP(ctx, url)
            if err != nil {
                return err
            }
            results[i] = data
            return nil
        })
    }
    
    if err := g.Wait(); err != nil {
        return nil, err
    }
    return results, nil
}

errgroup内部使用Context实现取消传播，任一goroutine返回error时自动cancel，其余goroutine收到信号后尽快退出。这种模式在高并发设计中既保证了并行效率，又避免了部分失败时的资源泄漏。