优化 Go 协程通信性能需合理使用 channel：优先有缓冲 channel 避免阻塞，按压测设缓冲大小（如 64/256/1024），严格顺序场景慎用无缓冲 channel；sender 关闭 channel，receiver 用 for range 自动退出；select 中加 default 或 ctx.Done() 防卡死；复用 sync.Pool 减少 GC；用 struct 替代 map，必要时序列化。
在 Go 中优化协程（goroutine）间通信性能，核心是合理使用 channel 并避免常见反模式。channel 本身不是瓶颈，但不当用法会引发阻塞、内存堆积或 Goroutine 泄漏，最终拖慢整体吞吐。
控制 channel 容量：用有缓冲 channel 替代无缓冲
无缓冲 channel（make(chan T)）要求发送和接收必须同步完成，极易造成 goroutine 阻塞等待。尤其在生产者-消费者节奏不一致时，会卡住整个流程。
建议根据业务吞吐和延迟容忍度设置合理缓冲区：
- 日志采集、指标上报等允许短时积压的场景，用
make(chan Entry, 1024)缓冲，避免因下游处理慢导致上游协程挂起 - 缓冲大小不必过大——超过 4KB 的 channel 缓冲区可能增加 GC 压力；优先通过压测确定临界值（如 64/256/1024）
- 若需严格顺序且低延迟（如命令通道），仍可用无缓冲 channel，但务必确保接收端始终活跃（例如用
for range持续消费）
及时关闭 channel 并避免重复发送
未关闭的 channel 会让 for range 接收方永远阻塞；向已关闭 channel 发送数据会 panic，而向未关闭 channel 无限发送又会造成接收方来不及处理、buffer 溢出、goroutine 积压。
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
关键做法：
- 只由 sender 关闭 channel，receiver 绝不关闭
- sender 完成后调用
close(ch)，receiver 用for v := range ch自动退出 - 在 select 中配合
default分支做非阻塞发送，防止因 receiver 暂时不可用而卡死：
select {
case ch // 成功发送
default:
// 丢弃或降级处理，不阻塞
复用结构体 & 避免频繁堆分配
通过 channel 传递大对象（如 map[string]interface{} 或长 slice）会触发大量堆内存分配和 GC 压力。更糟的是，若 sender 和 receiver 同时持有副本，还可能引发意外修改。
高效做法：
- 传递指针而非值：
chan *Request比chan Request更省内存（尤其结构体 > 16 字节） - 预分配对象池（
sync.Pool）复用高频小对象，例如：
var msgPool = sync.Pool{New: func() interface{} { return &Message{} }}
// 使用前 Get，用完 Reset 并 Put 回池 - 对固定字段消息，用 struct 替代 map；必要时用 flatbuffers 或 protobuf 序列化减少中间对象
用 context 控制生命周期，防 Goroutine 泄漏
channel 阻塞常源于 goroutine 忘记退出。比如启动一个监听 channel 的 goroutine，但没监听 cancel 信号，即使业务结束它仍在等待，持续占用栈内存和调度资源。
正确方式：
- 所有长期运行的 goroutine 都应接受
ctx context.Context参数 - 在 select 中加入
ctx.Done()分支：
select {
case msg := handle(msg)
case return // 清理并退出 - 启动 goroutine 时用
go fn(ctx, ...)，上层调用ctx.WithTimeout或ctx.WithCancel精确管理其存活时间
