微服务中channel用于任务协同而非数据传输，核心是控制执行节奏；需区分信号传递与结果传输，避免多生产者误用close()；按顺序执行时用无缓冲channel作同步点，如regDone、notifyDone等。
微服务里用 channel 做任务协同，不是“传数据”而是“控节奏”——多数失败源于混淆了信号传递和结果传输，或在多生产者场景下误用 close()。
多个服务协程间必须按顺序执行时，用无缓冲 channel 当同步点
比如 A 服务完成注册后，B 才能发通知，C 才能更新缓存。这不是并行，是硬依赖链。
- 每个依赖对单独建一个
chan struct{}，比如regDone、notifyDone - A 结束时写
regDone ；B 开头写 <code>，会阻塞直到 A 发信号 - 绝不能复用同一个 channel 让 B 和 C 都读 —— 它们会竞争，C 可能抢到信号，B 却永远卡住
- 若 A 可能 panic，改用
chan error，B 通过err, ok := 判断是否失败
多个下游服务需等全部上游响应才继续，WaitGroup + channel 关闭才是稳解
常见于聚合查询：订单服务要等库存、支付、物流三个协程都返回才组装响应。只用 range 读 channel 极易 panic 或死锁。
- 主协程声明
results := make(chan Result, N)（缓冲大小 ≥ 并发数） - 每个上游协程处理完后
results ，但**不关 channel** - 主协程用
sync.WaitGroup等所有上游退出，再close(results) - 消费者放心
for r := range results—— 关闭动作是单点、终局、无竞争的 - 若上游可能提前失败且需中断其余协程，必须引入
context.Context配合select
限流与超时必须用 context，别靠 time.After 或轮询
微服务调用外部 API 时，既要防雪崩又要防 hang 住整个请求链路。channel 自身不带超时能力。
立即学习“go语言免费学习笔记（深入）”；
- 统一用
ctx, cancel := context.WithTimeout(parentCtx, 5*time.Second)，把ctx传给所有下游协程 - 每个协程内部用
select监听ctx.Done()和自己的 result channel - 错误示例：在 for 循环里反复写
time.After(1s)—— timer 泄漏，GC 压力大 - 正确做法：复用一个
timer := time.NewTimer(...)，每次用完timer.Reset() - 收到
ctx.Err()后，立即清理资源（如关闭 HTTP 连接、释放 DB 连接池 slot）
并行任务结果要按原始顺序消费，别指望 channel 自带排序
比如批量调用 10 个用户服务，希望结果严格按 ID 1→10 输出，但 goroutine 返回时间不可控。
- 不要把结果直接塞进一个共用 channel 然后期望 range 出来有序 —— 不可能
- 为每个任务建独立 channel：
chans[i] = make(chan Result, 1) - 启动 goroutine 时，把对应索引 i 和 channel 一起传入，处理完后
chans[i] - 主协程按顺序
for i := range chans { res := ，天然保序 - 如果任务数极大（如万级），改用带索引的结构体 + 单 channel + 排序缓冲区，但多数微服务场景用独立 channel 更清晰
真正难的不是写 channel 语法，而是判断哪个环节该用 channel 传信号、哪个该用 WaitGroup 计数、哪个必须交由 context 控制生命周期——三者混用时，边界一旦模糊，死锁或 panic 就藏在下一次部署之后。
