根本原因是未控制goroutine生命周期和channel关闭时机：中间节点从已关闭channel读零值后继续转发，下游写入panic；或首节点未启动导致全链阻塞。需每节点只读写一次、写前用select+default检查channel是否open，首节点发sentinel而非close，避免无缓冲channel连超3级。
为什么 daisy chain 在 Go 里容易卡死或 panic
根本原因不是链太长，而是没控制好 goroutine 生命周期和 channel 关闭时机。常见现象是某个中间节点的 recv 从已关闭的 channel 读到零值后继续转发，下游 send 向已关闭 channel 写入直接 panic；或者所有 goroutine 都在等上游数据，但第一个没启动或被调度延迟，整条链挂住。
- 必须确保每个中间节点只读一次、只写一次，且写操作前检查下游 channel 是否仍 open（用
select+default或ok判断） - 首节点不能用
close(ch)结束，而应发一个 sentinel 值（如nil指针或自定义donestruct），让每层自己决定是否终止 - 避免用无缓冲 channel 连接超过 3 级——调度不确定性会让第 4 级永远收不到数据，除非所有 goroutine 同时就绪
select + default 是唯一靠谱的防阻塞写法
很多人用 ch 直接写，一旦下游 goroutine 慢半拍或已退出，这里就永久阻塞。Go 的 channel 写入不可取消，也没超时原语，只能靠非阻塞尝试。
- 正确写法是：
select { case ch <- val: // 成功 default: // 下游不接受，跳过或记录丢弃 } - 别用
time.After包裹写操作——这会创建额外 timer，高并发下内存暴涨；default零开销且语义清晰 - 如果必须保证送达，那就别用 daisy chain，改用带 buffer 的 channel 或结构化消息队列
测试链长极限时，runtime.GOMAXPROCS 比 CPU 核数更关键
实测发现：在 16 核机器上，GOMAXPROCS=1 时 200 级链稳定运行；设为 16 反而 50 级就开始丢数据。因为 goroutine 调度竞争加剧，channel 传递的时序彻底不可预测。
- 压测前先固定
runtime.GOMAXPROCS(1)，排除调度干扰，再逐步放开 - 每级加
runtime.Gosched()不解决问题，只会拖慢整体吞吐；真正要测的是“最差调度路径”下的稳定性 - 链长超过 100 后，建议把中间态转成 slice 一次性传递，而不是逐级 goroutine 转发——后者本质是把 CPU 密集型任务当 IO 做，违背 Go 并发设计初衷
真实场景中，context.Context 比 channel 更适合作为链控开关
用 channel 传 cancel 信号，容易出现 race：下游刚收到 close 通知，上游又往同一 channel 发新数据。而 context.WithCancel 天然线程安全，且能统一超时、截止时间、取消原因。
立即学习“go语言免费学习笔记（深入）”；
- 把每个节点包装成
func(ctx context.Context, in ，入口处用 <code>select监听ctx.Done() - 不要在链中混用
context和手动 close channel——取消信号来源一多，谁关谁、何时关就完全不可控 - 调试时打印
ctx.Err()而不是抓 channel 关闭 panic，能更快定位哪一级提前退出
实际跑满 500 级链时，最容易被忽略的是 GC 压力：每级 goroutine 持有 closure 引用上游变量，若中间有大 struct 或未释放的 map，几万 goroutine 就能把 heap 打爆。别只盯着 channel，得看 pprof heap profile。
