Go语言Echo框架Goroutine池应用-Golang-PHP中文网

echo 中直接 go fn() 是危险操作，因为 handler 生命周期结束时 context 被 cancel，但未监听 ctx.done() 的 goroutine 会持续阻塞在 select、channel 或 sleep 中，导致永久泄漏。

go语言echo框架goroutine池应用

为什么 Echo 里直接 `go fn()` 是危险操作

因为 Echo 的 handler 生命周期只到响应写出为止，但你启的 goroutine 可能还在跑——比如它正等一个 HTTP 调用返回、或往 channel 发数据、或 sleep 中。一旦 handler 结束，context.Context 被 cancel，但 goroutine 没监听 ctx.Done()，就会永远卡住，变成泄漏。

常见错误现象：pprof/goroutine?debug=2 显示大量 goroutine 停在 select { case 外面，或卡在 <code>http.Client.Do、time.Sleep、无缓冲 chan 上。

所有跨 handler 生命周期的 goroutine，必须接收并监听 context.Context
推荐从 c.Request().Context() 派生子 context（如 context.WithTimeout），别用全局 context
goroutine 内部要检查 ctx.Err() != nil 或用 select 响应 ctx.Done()，及时 return
避免在 goroutine 中直接写 response（c.JSON 等），handler 已结束，responseWriter 已失效

用 `errgroup.Group` 替代手写 `sync.WaitGroup` + `context`

手写 WaitGroup + context.WithCancel 组合容易漏掉 cancel 传播、error 收集或提前退出逻辑。而 errgroup.Group 天然支持三件事：并发执行、任意一个出错就取消其余、自动等待全部完成。

典型场景：一个 handler 需要同时查 DB、调下游 API、读缓存，任一失败就整体失败。

导入：import "golang.org/x/sync/errgroup"
初始化：g, ctx := errgroup.WithContext(c.Request().Context())
提交任务：g.Go(func() error { ... return nil })，函数签名必须是 func() error
等待结果：if err := g.Wait(); err != nil { ... }，err 是第一个非 nil 错误
注意：g.Go 内部已自动处理 ctx 取消，无需手动 select

如何安全复用 Echo 的 `echo.Context` 到 goroutine

不能把 c（即 echo.Context）直接传进 goroutine 并长期持有——它底层绑定了 request/response 生命周期，且内部字段（如 c.Response().Writer）在 handler 返回后不可再用。

Echo框架 5.1.0

Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。

下载

真正可安全传递的是它的「只读元信息」：ID、路径、查询参数、Header 子集，以及派生的子 context。

提取必要字段再传参：path := c.Path(); query := c.QueryParam("id"); go process(path, query, ctx)
若需访问 value，用 c.Get("key") 提前取出，别传 c 本身
绝对不要在 goroutine 中调用 c.JSON、c.String、c.Set 等会修改 context 状态的方法
Echo v4 默认不自动继承 cancel signal 到子 goroutine，必须显式用 context.WithTimeout 或 context.WithCancel