Go 并发治理入门：先管请求生命周期，再谈 goroutine 数量

很多 Go 服务的并发问题，并不是 goroutine 数量本身造成的，而是请求生命周期没有被管理：入口无限接收、下游没有超时、错误没有传播、取消没有收口。治理并发的第一步，是把一次请求当成一条完整链路来看。

并发治理到底治理什么

并发治理关注的是容量、生命周期和失败边界。容量决定服务能同时处理多少工作；生命周期决定 goroutine 什么时候应该退出；失败边界决定一个下游失败时是否要取消其它任务。只看 goroutine 数量，很容易把问题简化成“多开或少开”，而忽略了请求是否已经失控。

从入口开始画边界

一次 HTTP 请求进入服务后，通常会经过参数解析、缓存读取、多个下游查询、结果聚合和响应输出。每个阶段都应该知道自己的 deadline、是否可取消、失败后如何返回。入口层应该创建带超时的 context，并把它向下传递，而不是在深层函数里临时补超时。

生产环境里的常见失控形态

最常见的失控包括：热点 key 同时回源、慢接口拖住 goroutine、数据库连接池排队、重试放大流量、后台任务没有停止信号。它们表面不同，本质都是没有把容量预算和取消信号传递完整。

生产场景

适用于聚合接口、BFF 网关、订单详情页和运营后台查询页。这类接口通常会同时访问缓存、数据库和多个内部 HTTP 服务，单点超时会被并发扇出放大。

关键指标

• 请求总耗时 P95/P99 与 deadline 命中率
• goroutine 数量在流量回落后的恢复时间
• 下游超时、取消、排队和错误按依赖拆分统计

常见误区

• 只看 goroutine 数量，不看请求生命周期和资源预算
• 在深层函数里使用 context.Background 导致上游取消失效
• 把所有错误都包装成 500，无法区分主动取消和真正故障

落地建议

建议先画出一张请求链路图，把入口、并发扇出、缓存、SQL、HTTP 下游和响应输出全部标上预算。上线前用压测验证请求取消后 goroutine、连接池和队列都能在可接受时间内回落。

代码示例

ctx, cancel := context.WithTimeout(r.Context(), 800*time.Millisecond)
defer cancel()

result, err := svc.Query(ctx, req)
if err != nil {
    http.Error(w, err.Error(), http.StatusServiceUnavailable)
    return
}
json.NewEncoder(w).Encode(result)

上线检查

• 入口必须设置可解释的超时时间。
• 所有下游函数都接收 context。
• 任何 goroutine 都能在请求取消后退出。
• 监控里能看到超时、取消、排队和下游错误。