无缓冲 channel 不能在微服务 handler 中直接 send，因为 http handler 是单 goroutine 执行，若无对应接收者就绪，发送即阻塞导致死锁；必须确保接收端已启动或改用带缓冲 channel/异步 goroutine 发送。
无缓冲 channel 不能在微服务 handler 里直接 send
HTTP handler 是单 goroutine 执行的，ch 这种写法在无缓冲 <code>chan 上会立刻阻塞，因为没 goroutine 在另一端接收。微服务里常见错误是：中间件或 handler 里直接往 channel 发送请求、日志或指标，却忘了配接收协程。
- 正确做法：用
go func() { ch 启一个 goroutine 发送，或改用带缓冲的 <code>chan - 更稳妥的是搭配
select+ 超时：select { case ch - 千万别用
make(chan struct{}, 0)传业务数据——它只适合同步信号，比如done 通知 worker 退出
多个生产者时，close() 必须由协调者统一触发
微服务中常有多个 goroutine 并发写同一 channel（如多个 HTTP 请求写入任务队列），这时谁关 channel 就成了关键问题。如果任一生产者自行 close(ch)，其他还在发的 goroutine 会 panic: send on closed channel；如果都不关，消费者用 for range ch 就永远卡住。
- 必须用
sync.WaitGroup或context.WithCancel协调所有生产者完成后再关 - 典型结构：
defer close(ch)放在启动所有生产者的那个 goroutine 末尾，不是放在每个生产者内部 - 若用 context 控制生命周期，应在
后显式 <code>close(ch)，而不是依赖 defer（defer 可能在 ctx 取消前就执行）
for range 消费 channel 前，确保有人会关它
微服务里大量用 for v := range ch 处理流式数据（如事件总线、消息队列消费者），但只要没人调用 close(ch)，这个循环就永远不会退出——goroutine 泄漏，连接不释放，内存持续增长。
- 检查所有向该 channel 写数据的路径：是否每条 exit 路径都覆盖了
close(ch)？包括 error 分支、timeout 分支、panic recover 分支 - 避免“只起一个 goroutine 写，写完 return 却忘了 close”这种低级遗漏
- 如果 channel 是从外部传入（如函数参数
ch ），接收方不应假设它会被关闭，应配合 <code>context.Context主动退出
缓冲区大小不是越大越好，要匹配背压预期
微服务中常把 channel 缓冲设成 1024 甚至 10000，以为能“扛住流量”，结果只是把问题从阻塞延迟转移到内存泄漏和 GC 压力上。
- 缓冲大小本质是“最多允许积压多少条未处理消息”，不是性能调优参数
- 典型安全值：
make(chan *Request, 1)用于解耦 handler 和 worker；burst 场景按峰值差设，比如上游 QPS 500、下游吞吐 300 → 缓冲 256 已足够 - 元素大（如含
[]byte的结构体）时，缓冲 64 就算高水位；再大要考虑 GC 扫描变慢、内存占用线性增长 - 真正危险的不是满缓冲，而是消费逻辑被条件跳过（比如
if enabled { 漏掉 else），导致发送端永久等待
微服务里 channel 死锁最麻烦的不是单点遗漏，而是多组件协作时关闭时机错位——比如 A 服务发完关 channel，B 服务刚启动还没开始收；或者 context 取消了，但 channel 关闭逻辑被 defer 延后执行。这类问题不会报 panic，只会让 goroutine 静默堆积，几天后才暴露。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
