Go 并发编程：生产服务里 goroutine 要有退出路径
Go 并发编程：生产服务里 goroutine 要有退出路径
一、goroutine 泄漏比慢查询更隐蔽
Go 的 goroutine 很轻量，但轻量不等于可以随便开。生产服务里常见的问题是：请求取消了，后台 goroutine 还在跑；通道没人读，发送方永久阻塞；定时任务没有 stop；重试循环没有退出条件。短时间看不出问题，运行几天后内存、连接和 CPU 慢慢被吃掉。
并发编程的第一原则，是每个 goroutine 都要知道什么时候结束。能启动，就要能退出；能等待，就要能取消；能重试，就要有限制。否则服务看似正常，实际埋着持续损耗。
二、并发链路：取消信号要传到底
flowchart LR A[HTTP 请求] --> B[创建 context] B --> C[查询数据库] B --> D[调用下游服务] B --> E[后台处理] C --> F[返回结果] D --> F E --> Fcontext 不是装饰品。请求取消、超时、服务关闭时，取消信号应该传到数据库、HTTP 客户端、队列消费和后台任务。只在最外层设置 timeout，没有传到下游，效果很有限。
三、代码示例：用 errgroup 管理并发
下面是一个简化示例，展示如何让多个并发任务共享取消。
package service import ( "context" "net/http" "golang.org/x/sync/errgroup" ) func Handle(ctx context.Context, ids []string) error { g, ctx := errgroup.WithContext(ctx) for _, id := range ids { id := id g.Go(func() error { req, err := http.NewRequestWithContext(ctx, http.MethodGet, "https://api.example.com/items/"+id, nil) if err != nil { return err } resp, err := http.DefaultClient.Do(req) if err != nil { return err } defer resp.Body.Close() return nil }) } return g.Wait() }errgroup 的好处是，一旦某个任务失败，context 会取消，其他任务有机会停止。注意循环变量要重新绑定，否则旧版本 Go 中容易踩坑。生产中还要加并发上限，避免 ids 很多时同时打爆下游。
四、工程边界：并发上限比并发数量更重要
很多性能问题不是因为并发少，而是因为没有上限。数据库连接池只有 50 个，却开 500 个 goroutine 同时查询，最终只是把等待从应用层挪到数据库层。看起来服务很努力，实际吞吐不一定更高，延迟还会更差。
建议为每类下游设定单独并发池，并监控等待时间。等待时间上升，说明系统已经接近容量边界。此时要么扩容下游，要么降级功能，要么拒绝部分请求。无限排队是最不负责任的选择，因为它让用户和系统都不知道什么时候会恢复。
还要处理服务关闭。SIGTERM 到来时，HTTP 服务应停止接收新请求，给已有请求一个优雅退出窗口，后台 goroutine 监听 shutdown context。容器环境里，优雅退出不是可选项。Kubernetes 会给 Pod 终止时间，应用必须配合，否则滚动发布时就会制造随机失败。
生产落地补充：从能跑到可维护
从生产落地角度看，这类方案不能只停留在主流程。更关键的是把输入校验、失败分支、资源上限和回滚路径提前写清楚。主流程通常容易在演示环境里跑通，真正暴露问题的是异常输入、依赖抖动、并发放大和权限边界。一篇技术方案如果没有解释这些约束，读者很难判断它能否放进真实系统。
评估时建议先定义三类指标：正确性指标、稳定性指标和成本指标。正确性指标回答结果是否可信，稳定性指标回答失败时是否可控，成本指标回答持续运行是否划算。三类指标要同时进入验收清单，不能只用平均耗时或单次成功率证明方案有效。
实现层面还需要把观测数据留出来。日志至少包含请求标识、关键参数摘要、耗时、状态和错误类型；指标至少覆盖成功率、超时率、重试次数和队列长度；必要时再补 Trace 关联上下游调用。这样排查问题时不用靠猜，也能区分是代码逻辑、外部依赖还是容量配置导致的故障。
测试策略也要覆盖边界条件。除了正常样例，还要准备空输入、超大输入、重复请求、依赖超时、权限不足和部分成功等用例。涉及并发时，应补充压力测试和资源泄漏检查；涉及数据处理时，应补充幂等校验和结果一致性校验。测试不是装饰，而是保证后续重构仍然可信的依据。
五、总结
Go 并发编程的生产重点，不是炫耀 goroutine 数量，而是保证每个并发任务可取消、可等待、有上限、能退出。把这些边界写清楚，服务才会在长时间运行后仍然稳定。