应按需复用、延迟启动、避免裸建goroutine；用sync.Pool缓存依赖对象减少GC；用worker pool限制并发数并复用goroutine，避免每任务启一个导致线性增长。

频繁创建 goroutine 会导致调度器压力上升、内存分配增多、GC 负担加重，尤其在高并发短生命周期任务中（如 HTTP 请求处理、消息解析），go f() 每秒调用上万次时，开销会明显拖累吞吐量。关键不是“少用 goroutine”，而是“按需复用、延迟启动、避免裸建”。

用 sync.Pool 缓存 goroutine 所依赖的上下文对象

goroutine 本身轻量，但常伴随结构体、缓冲区、连接等堆分配。直接在 go 语句里 new 会导致高频 GC。

• 不要在 goroutine 启动前 new 大对象：go func() { data := make([]byte, 4096); process(data) }()
• 改用 sync.Pool 预分配并复用：

  var bufPool = sync.Pool{
      New: func() interface{} {
          return make([]byte, 0, 4096)
      },
  }
  // 使用时
  buf := bufPool.Get().([]byte)
  buf = buf[:0]
  // ... use buf
  bufPool.Put(buf)

• sync.Pool 不保证 Get 一定命中，不能依赖其“一定有值”；Put 前确保清空敏感字段，避免数据残留

用 worker pool 模式限制并发数 + 复用 goroutine

把“为每个任务启一个 goroutine”改为“固定 N 个长期运行的 goroutine 从队列取任务”，能彻底消除创建/销毁开销，并控制资源上限。

Golang Spf13 Viper

Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。

下载

• 典型错误：每来一个请求就 go handle(req) → goroutine 数随 QPS 线性增长
• 正确做法：启动固定数量的 worker，用 chan 分发任务

  type Worker struct {
      jobs <-chan *Request
      done chan<- struct{}
  }
  func (w *Worker) Run() {
      for req := range w.jobs {
          handle(req)
      }
      w.done <- struct{}{}
  }
  // 启动 8 个 worker
  jobs := make(chan *Request, 100)
  done := make(chan struct{}, 8)
  for i := 0; i < 8; i++ {
      go (&Worker{jobs: jobs, done: done}).Run()
  }

• 注意 jobs channel 容量要设合理缓冲，避免 sender 阻塞；worker 异常退出需有重启或告警机制

用 runtime.Gosched() 替代短时 goroutine 拆分

有些场景本意只是“让出 CPU 避免阻塞”，比如循环中做简单计算但想防止单次执行过长。此时起 goroutine 是过度设计。

立即学习“go语言免费学习笔记（深入）”；

• 错误示范：go func() { for i := 0; i —— 只为 yield，却引入调度开销
• 更轻量的做法：在循环中插入 runtime.Gosched()，主动让出时间片

  for i := 0; i < 1e6; i++ {
      compute(i)
      if i%1000 == 0 {
          runtime.Gosched() // 每千次让出一次
      }
  }

• runtime.Gosched() 不创建新 goroutine，仅提示调度器可切换，适用于已知耗时可控、无需真正并发的场景

goroutine 的创建成本虽低（约 2KB 栈 + 调度元信息），但在微服务或网关类系统中，每秒数万次的创建销毁仍会成为瓶颈。真正难的是判断哪些该池化、哪些该合并、哪些其实根本不需要并发——这得看任务粒度、IO 类型和超时约束，不能只盯着 go 关键字删减。