goroutine 泄漏主因是 HTTP handler 中未受 context 管控的协程；应统一用 context.WithTimeout+errgroup 实现超时控制与级联取消，模板渲染禁用协程。
Web 服务中 goroutine 泄漏的典型表现
HTTP handler 里直接起 go 协程但没做生命周期控制，是最常见的泄漏源头。比如在 http.HandlerFunc 中启动一个异步日志上报协程，却没绑定请求上下文或设置超时，这个协程可能在响应返回后继续运行数分钟甚至卡死，最终拖垮整个服务。
- 现象：pprof 查看
/debug/pprof/goroutine?debug=1显示协程数持续上涨，且多数处于select或chan receive状态 - 根本原因：协程脱离了请求生命周期，无法被 GC 或主动退出
- 正确做法：所有后台协程必须受
context.Context管控，用ctx.Done()触发退出，或通过sync.WaitGroup显式等待
gorilla/mux + context.WithTimeout 的标准组合写法
路由 层是并发控制的第一道关卡。用 gorilla/mux 搭配 context.WithTimeout 能在入口就切断慢请求，避免协程堆积。
func handleUser(ctx context.Context, w http.ResponseWriter, r *http.Request) {// 为每个请求设置 5 秒总超时（含下游调用）ctx, cancel := context.WithTimeout(ctx, 5*time.Second) defer cancel() userID := mux.Vars(r)["id"] user, err := fetchUser(ctx, userID) // fetchUser 内部必须检查 ctx.Err() if err != nil { if errors.Is(err, context.DeadlineExceeded) {http.Error(w, "timeout", http.StatusGatewayTimeout) return } http.Error(w, "internal error", http.StatusInternalServerError) return } json.NewEncoder(w).Encode(user) }-
fetchUser必须接收ctx并在数据库查询、HTTP 调用等阻塞点传入 - 不能只在 handler 开头设超时，下游函数不响应
ctx就等于没设 - 别用
time.AfterFunc替代context.WithTimeout，它无法取消已启动的 goroutine
并发调用多个微服务时怎么避免级联失败
用 errgroup.Group + context 是 Go 生态最稳妥的并发扇出方案。它自动聚合错误、支持取消传播、不需手写 WaitGroup。
func fetchUserProfile(ctx context.Context, userID string) (profile Profile, posts []Post, err error) {g, ctx := errgroup.WithContext(ctx) g.Go(func() error {p, e := fetchProfile(ctx, userID) if e == nil {profile = p} return e }) g.Go(func() error {ps, e := fetchPosts(ctx, userID) if e == nil {posts = ps} return e }) return profile, posts, g.Wait() // 任一子协程出错，其余自动取消}- 所有子协程共享同一个
ctx，任一失败都会触发其他协程的ctx.Done() - 如果某个下游服务响应极慢（比如 30s），而主请求超时是 5s，它会在 5s 后被强制中断，不会拖累整体
- 别用
sync.WaitGroup+chan手动收集结果，容易漏关 channel 或 panic
模板渲染阶段要不要开 goroutine
不要。HTML 模板渲染是纯 CPU 绑定操作，html/template.Execute 本身不阻塞 I/O，开 goroutine 只会增加调度开销和 内存占用。
立即学习“go 语言免费学习笔记（深入）”；
- 实测：1000 次模板渲染，单协程比 10 协程并行快 2–3 倍（Go 1.22，Mac M2）
- 唯一例外：渲染前需要从多个非关联数据源并发加载（如用户信息 + 配置项 + 实时统计），此时应在
Execute前用errgroup预加载，而非在模板内起协程 - 如果用了
template.FuncMap注册了 HTTP 调用函数，那是设计错误——模板逻辑不该含 I/O
并发不是加 go 就完事。真正难的是判断哪里该并发、哪里该串行，以及让每个 goroutine 都有明确的退出路径。很多线上事故，都出在以为“开了协程就快了”，却忘了它也可能永远不结束。
