go中不能直接在echo handler里用go func()，因其会导致goroutine泄漏、无上下文控制、错误无法传播、下游资源打崩；应使用errgroup.group或自建worker pool实现可控并发。
Go 里没有真正的“Goroutine Pool”，Echo 框架本身也不提供内置线程池或协程池；所谓“基于 Goroutine Pool 的异步处理”，实际是开发者在 Echo 的 HTTP handler 中手动构造 worker pool 或用 errgroup.Group 控制并发，避免裸写 go func() 导致失控增长。
为什么不能直接在 Echo handler 里用 go func() 启动任务
很多人一想“异步”，就在 echo.HandlerFunc 里直接写 go doSomething() —— 这会导致：
- 每个请求都 spawn 新 Goroutine，1000 QPS 就可能瞬间创建上千个 Goroutine，栈内存暴涨、GC 压力飙升
- 没上下文控制：请求取消（如客户端断连）时，后台 Goroutine 仍继续跑，变成 goroutine leak
- 没错误传播：某个子任务 panic 或返回 error，上层完全无法感知和响应
- 下游资源打崩：比如同时发起 500 个 DB 查询，数据库连接池直接耗尽
用 errgroup.Group 实现带上下文的可控并发
errgroup.Group 是标准库推荐方式，它把 context 取消、错误聚合、等待完成三件事绑在一起，比手写 channel + waitgroup 更稳。
典型用法：
func handleAsyncTasks(c echo.Context) error {
ctx, cancel := context.WithTimeout(c.Request().Context(), 5*time.Second)
defer cancel()
eg, ctx := errgroup.WithContext(ctx)
// 注意：循环变量要传参，别闭包捕获 i
for i := range tasks {
task := tasks[i]
eg.Go(func() error {
return processTask(ctx, task)
})
}
if err := eg.Wait(); err != nil {
return echo.NewHTTPError(http.StatusInternalServerError, err.Error())
}
return c.JSON(http.StatusOK, map[string]string{"status": "done"})
}
关键点：
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
-
eg.Wait()阻塞直到所有子任务结束或任一出错/超时 - 一旦
ctx超时或被取消，所有正在运行的processTask都会收到ctx.Err()，应主动检查并退出 - 不要在
eg.Go闭包里直接用循环变量（如for i := range tasks { eg.Go(func(){ use(i) }) }），必须显式传参
需要固定并发数？自己建 worker pool + buffered channel
当任务量极大（如批量写日志、调用第三方 API 5000 次），且必须限制并发数（比如最多 20 个 HTTP 客户端同时发请求），就得自己搭 worker pool：
- 启动固定数量 Goroutine（如 20 个），每个都从
jobs chan *Task里取任务 -
jobs必须带缓冲（如make(chan *Task, 100)），否则生产者容易阻塞 - 生产者（handler）只负责往 channel 发送任务，不关心谁执行、何时完成
- 注意关闭 channel：所有任务投递完后，
close(jobs)，worker 才能自然退出
这种模式适合「吞吐稳定、资源敏感」场景，但比 errgroup 多一层抽象，调试和监控成本略高。
别被“异步响应”误导：Echo 本身不支持真正的异步 HTTP 返回
Echo 的 handler 函数签名是 func(echo.Context) error，它必须同步返回 response。所谓“异步处理”，只是把耗时逻辑挪到后台 Goroutine，然后立刻返回一个“已接收”响应（比如 202 Accepted），后续结果靠轮询、Webhook 或消息队列通知。
常见错误是：
- 在 handler 里
go func(){ c.JSON(...) }——c是栈变量，Goroutine 里访问可能 panic 或写到已关闭的 connection - 以为
echo.StartServer开了多线程，其实它只是启动一个监听 Goroutine，每个连接由独立 Goroutine 处理，仍是同步模型
真正要注意的，从来不是“怎么开更多 Goroutine”，而是“怎么让它们不乱跑、不卡死、不出错、可取消”。Goroutine 很轻，失控的调度代价却很重。
