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 数量而是保证每个并发任务可取消、可等待、有上限、能退出。把这些边界写清楚服务才会在长时间运行后仍然稳定。
