使用 Golang 框架简化异步 IO 操作

在处理高并发场景时，IO操作的编排往往是让人头疼的一环。尤其是当你要在一个HTTP handler里同时发起多个下游请求时，问题就显得尤为突出。今天就聊聊这个话题，看怎么用Go的标准库和几个核心工具，把这些事理顺。 ### 为什么 `net/http` 默认不是异步的？ 先抛个结论：Go 的 `net/http` 服务器本身就是并发的——每个请求都跑在独立的 goroutine 里。但注意，它可没有提供什么“异步IO回调”或者“非阻塞等待”的抽象。你写个 `http.HandleFunc`，函数体里调 `db.QueryRow` 或 `http.Post`，整个 goroutine 就卡在那里等结果。这本质上只是靠 goroutine 数量堆出来的并发，而不是 IO 多路复用意义上的“异步”。 真正麻烦的场景是：一个 HTTP handler 需要同时发 3 个下游 API 请求，等全部返回后再聚合；或者要轮询多个设备状态，但不想为每个设备单独开 goroutine 再手动用 channel 编排。这时候标准库就帮不上忙了。 有几个关键点需要先明确： - 别指望标准库自动帮你做并发控制或错误聚合。`sync.WaitGroup` 和 `errgroup.Group` 是你绕不开的搭档。 - `context.Context` 必须传到底层调用，否则超时和取消会失效——这在嵌套 HTTP 调用或数据库查询时尤其致命。 - 用 goroutine 匿名起一堆请求很容易，但如果没加 `recover`，或者没设 `context.WithTimeout`，一个不小心就可能让整个 handler 卡死，甚至泄漏 goroutine。 ### 用 `errgroup.Group` 并发发起多个 HTTP 请求 这是最常见、也最稳妥的简化方式。它把并发控制、错误传播、上下文取消全包了，比裸写 `sync.WaitGroup` 加 channel 的方式清晰太多。 ``` g, ctx := errgroup.WithContext(r.Context()) var resp1, resp2 *http.Response g.Go(func() error { var err error resp1, err = http.DefaultClient.Do(http.NewRequestWithContext(ctx, "GET", "https://api.a.com/data", nil)) return err }) g.Go(func() error { var err error resp2, err = http.DefaultClient.Do(http.NewRequestWithContext(ctx, "GET", "https://api.b.com/status", nil)) return err }) if err := g.Wait(); err != nil { http.Error(w, err.Error(), http.StatusInternalServerError) return } // 此时 resp1 和 resp2 已就绪，可读 Body ``` 几个容易踩的坑： - 必须用 `http.NewRequestWithContext`，不要用 `http.Get`——后者会忽略传入的 `ctx`。 - `errgroup.Group` 在任一子任务出错时，会立刻通过内部共享的 `ctx` 取消其余任务，避免资源浪费。 - 注意 `resp.Body` 仍需手动 `Close()`，`errgroup` 不会替你处理这个。 ### 数据库查询也适用 `errgroup` 吗？ 可以，但前提是驱动得支持 context。比如 `database/sql` 的 `QueryRowContext`、`ExecContext` 都是安全的；而老式的 `QueryRow` 会忽略 timeout，用了等于没用。 - PostgreSQL 驱动（`lib/pq`）和现代 `pgx` 都完整支持 context 取消。 - MySQL 驱动（`go-sql-driver/mysql`）从 v1.5+ 开始支持 `QueryContext`，旧版本则会静默忽略。 - **特别注意**：不要在 `g.Go` 里直接用 `tx.QueryRow`——事务对象不是并发安全的。正确的做法是为每个 goroutine 单独 `BeginTx`，或者改用连接池级别的并发。 一个典型错误是：用同一个 `*sql.DB` 发起多个查询没问题，但共享一个 `*sql.Tx` 就会引发 panic，报 `driver: bad connection` 或 `transaction is already closed`。 ### 要不要引入第三方框架如 `gofiber` 或 `echo`？ 说实话，它们本身不解决异步 IO 简化的问题。Fiber 的 `c.Async` 只是把 handler 函数扔进 goroutine，不处理错误聚合、上下文传播或并发限制——到头来，你还是得自己上 `errgroup`。 - 框架的价值在于路由、中间件、JSON 序列化等，而不是替代 `errgroup` 或 `context`。 - 有些封装库（比如 `github.com/sony/gobreaker`）能帮你加熔断，但那是另一层关注点，和“并发发起多个 IO”无关。 - 真要简化，与其换框架，不如把 `errgroup` 封装成一个带默认超时的工具函数，然后在多个 handler 里复用。 最后说一个最容易被忽略的问题：所有 IO 操作链路上的每一步，都得显式接收并传递 `context.Context`。漏掉一层，整条链就会失去取消能力。比如 HTTP handler 传了 ctx 给 `errgroup`，但里面调用的某个 SDK 方法没暴露 Context 参数，那你就只能干等着。