扇入（fan-in）指多个goroutine向同一channel汇聚数据的并发模式，需用select非阻塞轮询或独立转发goroutine实现，避免死锁与丢帧。
什么是扇入（Fan-in）在 Go 并发模型里的实际表现
扇入不是 Go 语言内置概念，而是对「多个 chan 向一个 chan 汇聚数据」这种模式的通用叫法。它常用于把多个传感器 goroutine 的输出统一收口到一个消费端，比如实时绘图或日志聚合。
关键点在于：你不能直接把多个 chan int 赋值给一个 chan int；必须靠 goroutine + select 或 range 来桥接。否则会 panic 或死锁。
常见错误现象：fatal error: all goroutines are asleep - deadlock，往往是因为忘了启动接收 goroutine，或者某个传感器 channel 没被读完就关闭了，导致其他 channel 被阻塞。
- 每个传感器应独立运行 goroutine，向自己的
out chan int发送数据 - 扇入 goroutine 必须用
select非阻塞轮询所有输入 channel，或用for range（仅当 channel 明确会关闭） - 如果传感器可能长期不发数据，别用无缓冲 channel——容易卡住；建议用带缓冲的
make(chan int, 16)
用 select 实现多 sensor channel 扇入的最小可靠写法
这是最可控、最不容易出错的方式，尤其适合传感器频率不一致、可能中途断连的场景。
立即学习“go语言免费学习笔记（深入）”；
核心逻辑是启动一个 goroutine，持续 select 所有 sensor channel，只要任一 channel 有数据就转发出去。不需要等全部就绪，也不依赖关闭信号。
func fanIn(sensors ...<code>chan int</code>) <code>chan int</code> {
out := make(chan int)
go func() {
defer close(out)
for {
select {
<code>case v := </code><code><-sensors[0]</code>:
out <code><- v</code>
<code>case v := </code><code><-sensors[1]</code>:
out <code><- v</code>
// ……手动展开每个 sensor，或用反射/切片封装（见下节）
<code>default</code>:
// 防止空转，加小延迟但非必需
time.Sleep(time.Microsecond)
}
}
}()
return out
}注意：select 不能动态遍历 channel 切片，所以要么手动展开（适合 sensor 数量固定且少），要么改用反射或额外 goroutine 封装——但反射会损失类型安全，不推荐用于生产传感器系统。
- 不要在
select里混用default和无缓冲 channel：可能导致数据丢失（default立即跳过） - 如果 sensor 数量 > 5，建议用「每个 sensor 单独起 goroutine 转发到公共 channel」替代大
select，更清晰也更好调试 -
time.Sleep在default分支里只是防 CPU 空转，实际部署时可去掉，靠 sensor 数据自然驱动
传感器异常退出时如何避免扇入 goroutine 卡死
真实硬件传感器可能重启、断线、超时返回错误，对应 goroutine 可能提前退出，但它的 output channel 若没被关闭或读完，扇入端就会永远等下去。
最稳妥的做法不是靠 channel 关闭，而是让每个 sensor goroutine 自己负责清理，并通过 context 控制生命周期。
- 每个 sensor goroutine 应接收
context.Context，并在ctx.Done()时主动退出并关闭自己的 output channel - 扇入 goroutine 不依赖
close()，而用select+default或定时检测，避免单点阻塞 - 不要用
for range直接读 sensor channel——一旦某个 sensor 停发又不关 channel，整个扇入就卡住 - 可在扇入前加一层「带超时的读取包装器」：
func readWithTimeout(ch <code>chan int, timeout time.Duration) (int, bool)，提升鲁棒性
实时显示时，扇入后的数据怎么不丢帧又不堆积
扇入本身只是汇聚，真正影响显示效果的是下游消费速度。如果绘图或日志写入太慢，数据会在扇入 channel 缓冲区堆积，最终 OOM 或严重延迟。
解决思路不是压低传感器频率，而是做「背压控制」：让扇入 channel 缓冲区大小匹配下游处理能力，并允许丢弃旧帧。
- 设置扇入 channel 缓冲区为固定小值，例如
make(chan int, 32)，而不是make(chan int, 1000) - 用带缓冲的 channel +
select非阻塞发送：select { case out ，新数据来时旧数据自动丢弃 - 若需保序且不能丢，改用 ring buffer（如
github.com/Workiva/go-datastructures/queue），但会增加依赖和 GC 压力 - 显示端每秒刷新 30 帧就够了，没必要把所有 sensor 原始采样都推过去——可在扇入后加简单滑动平均或降频逻辑
真正难的从来不是怎么把数据汇进来，而是怎么让「汇聚节奏」跟上「显示节奏」，同时不让某一个传感器拖垮整体。这需要在 channel 容量、goroutine 生命周期、context 超时三者之间反复调参，没有银弹。
