无缓冲 channel 易致 goroutine 频繁阻塞，应改用带缓冲 channel；缓冲区大小需权衡内存与延迟，典型值如 make(chan *LogEntry, 1024)。

channel 容量设置不当导致频繁阻塞

无缓冲 channel（make(chan int)）在每次发送和接收时都需双方 goroutine 同时就绪，实际压测中容易成为性能瓶颈。尤其在生产者快、消费者慢的场景下，send 会直接挂起 goroutine，触发调度开销。

改用带缓冲 channel 可解耦收发节奏，但缓冲区不是越大越好——过大会增加内存占用，还可能掩盖消费延迟问题。

• 典型合理值：根据业务单次批处理量设定，例如日志采集常用 make(chan *LogEntry, 1024)
• 避免 make(chan int, 1 这类“保险式”大缓冲，它会让 channel 占用数 MB 内存且延迟不可控
• 若无法预估流量，可用 select 配合 default 实现非阻塞写入，再降级到本地队列或丢弃

频繁创建/关闭 channel 引发 GC 压力

在循环内反复调用 make(chan ...) 或对已关闭 channel 执行 close()，会快速生成大量短期对象，加剧垃圾回收频率。pprof 中常表现为 runtime.makeslice 和 runtime.chansend 占比异常高。

关键原则：channel 是长生命周期通信载体，不是一次性的消息容器。

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

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

• 将 channel 作为结构体字段或包级变量复用，而非函数局部变量
• 禁止在 for 循环里 ch := make(chan int); go worker(ch) —— 应提前创建好 channel 并复用
• 关闭 channel 仅应在明确“所有发送者已退出”时由最后一个发送者调用；接收端永远不要 close

range 遍历未关闭 channel 导致 goroutine 泄漏

for v := range ch 会一直阻塞等待新值，如果 sender 忘记 close 或 panic 退出，该 goroutine 就永久挂起，形成泄漏。pprof 查看 goroutine 数量持续上涨即可定位。

必须确保 range 的 channel 有确定的关闭时机，且关闭行为可被 receiver 感知。

• sender 完成后显式调用 close(ch)，receiver 才能安全退出
• 若 sender 有多个，用 sync.WaitGroup 等待全部完成再 close，不能靠计数器——竞态风险高
• 紧急退出场景可用 context.Context + select 替代纯 range，例如：

  for {
      select {
      case v, ok := <-ch:
          if !ok {
              return
          }
          process(v)
      case <-ctx.Done():
          return
      }
  }

用 select 处理多 channel 时忽略 default 分支

当 select 中所有 channel 都不可读/写时，若无 default，goroutine 会阻塞，这在需要响应超时、心跳或控制信号的场景下极危险。

更隐蔽的问题是：即使写了 default，若其中逻辑耗时过长（如打印日志、调用 HTTP），也会拖慢主循环吞吐。

• default 分支应尽量轻量，只做标记或投递事件，不执行 IO 或复杂计算
• 避免在 select 中混用同步操作（如直接调用 time.Sleep），改用 time.After channel
• 高吞吐服务中慎用 select 嵌套，易引发调度延迟；可考虑用 chan struct{} 统一通知事件

真正卡住性能的往往不是 channel 本身，而是对「何时关闭」「谁负责关闭」「缓冲区是否匹配真实吞吐」这些细节的模糊处理。一个没关的 channel，比十个低效算法更难排查。