Go函数返回chan需显式声明方向以增强类型安全，生产者返回
函数返回 chan 类型要显式声明方向
Go 中函数返回通道，必须明确是只读、只写还是双向通道。直接写 chan int 默认是双向，但多数场景下应限制方向以增强类型安全和可读性。比如生产者函数只往里塞数据，就该返回 （只读）；消费者接收方则应接收该类型，不能往里写。
常见错误是函数签名写成 func produce() chan int，调用方误以为能往返回的通道里写，结果 panic 或逻辑混乱。正确做法是让返回值“收窄”能力：
func produce() —— 调用方只能从该通道接收func consume(ch —— 参数只接收，无法发送- 内部仍可用
chan int创建，再强制转为返回
用 goroutine 封装通道初始化，避免阻塞调用方
如果函数在返回通道前就试图发送数据（比如启动一个生成器），而调用方还没开始接收，就会死锁。典型错误写法：ch := make(chan int); ch —— 这行不通。
必须把发送逻辑放到 goroutine 里，让函数立即返回通道，由后台协程异步推数据：
立即学习“go语言免费学习笔记（深入）”；
func countTo(n int) <-chan int {
ch := make(chan int)
go func() {
defer close(ch)
for i := 1; i <= n; i++ {
ch <- i
}
}()
return ch
}注意：一定要 defer close(ch)，否则接收方可能永远等不到关闭信号；也别忘了用 range 配合 close 才能安全退出循环。
Web仪表盘，用于审批OpenClaw设备与通道配对、管理连接，并可从浏览器访问实时终端。
多个通道组合时优先用 select + nil 通道控制开关
构建并发管道（如过滤、转换、合并）时，常需动态启用/禁用某个输入源。直接关掉通道会 panic，更安全的做法是把通道变量设为 nil，让它在 select 中永久不可选中。
例如实现一个带开关的扇入（fan-in）：
func fanIn(in1, in2 <-chan int) <-chan int {
out := make(chan int)
go func() {
defer close(out)
for in1 != nil || in2 != nil {
select {
case v, ok := <-in1:
if !ok { in1 = nil } else { out <- v }
case v, ok := <-in2:
if !ok { in2 = nil } else { out <- v }
}
}
}()
return out
}这里 in1 = nil 后，对应 case 永远不会触发，相当于“软关闭”。比用额外 done channel 或 mutex 更轻量，也更符合 Go 的通道哲学。
注意缓冲区大小对背压和内存的影响
返回的通道是否带缓冲，直接影响调用方行为。无缓冲通道要求发送和接收严格同步，适合精确控制节奏；有缓冲通道（如 make(chan int, 100)）能缓解瞬时压力，但也可能掩盖下游处理慢的问题，导致内存堆积。
实际选择依据是使用场景：
- 事件通知类（如信号、状态变更）—— 用无缓冲或小缓冲（
1） - 批处理流水线（如日志聚合、数据清洗）—— 缓冲大小应匹配单次处理吞吐，通常不超过 16–64
- 绝不要用大缓冲（如
10000）代替流量控制，那只是把问题推迟到 OOM
缓冲区大小一旦定下就无法修改，且不体现在函数签名里，所以文档或变量命名得体现意图，比如叫 eventCh 或 batchCh，而不是笼统的 ch。
