Golang channel作为函数参数的设计建议

Go编译器要求channel传参必须指定方向：不能将无方向的chan T直接传给只读（

channel 传参必须指定方向

Go 编译器不允许把无方向的 chan T 直接传给只读或只写的函数，否则会报错 cannot use ch (type chan int) as type 。方向是类型的一部分，不是可选修饰。

实操建议：

• 接收方只读数据，参数用 （只读通道）
• 发送方只写数据，参数用 chan（只写通道）
• 函数内部需双向操作（如关闭、判断是否关闭），才用 chan T，但要格外小心协程安全
• 调用方传入的原始通道可以隐式转换为更受限的方向类型，例如 chan int 可传给 func f(，反之不行

不要在函数内关闭传入的 channel

关闭一个已被其他 goroutine 使用的 chan 是危险操作，会导致 panic：panic: close of closed channel 或更隐蔽的竞态。Go 没有运行时检查谁“拥有”通道，但设计上应由 sender 侧统一管理生命周期。

实操建议：

• 函数签名中若参数是 chan，说明该函数是 sender，可考虑关闭（但仍需确认是否真为唯一 sender）
• 若参数是 ，绝对不要调用 close() —— 这属于越权
• 需要通知结束？用额外的 done 参数，而不是关 channel
• 如果必须传递“可关闭的通道”，显式用 *chan T 并文档注明所有权转移，但极不推荐

避免 channel 类型暴露在公共 API 中

把 chan T 放在导出函数签名里，等于把并发模型和生命周期管理强耦合进接口，后续难以替换为其他通信方式（如回调、事件总线、共享内存），也难做 mock 测试。

实操建议：

• 对外暴露的函数尽量用普通参数 + callback 函数，例如 func Process(items []T, onItem func(T)) error
• 内部实现可用 channel 调度，但对调用方透明
• 若必须用 channel（如流式处理 SDK），提供封装类型，比如 type ItemStream struct { ch ，隐藏底层 chan 类型
• 避免在结构体字段中直接存裸 chan，改用方法控制收发逻辑

func NewItemStream() *ItemStream {
    ch := make(chan Item, 16)
    return &ItemStream{ch: ch}
}
func (s *ItemStream) Send(item Item) {
s.ch <- item
}
func (s *ItemStream) Output() <-chan Item {
return s.ch
}

注意缓冲区大小与阻塞行为对调用方的影响

函数接收 chan T 时，无法得知它是带缓冲还是无缓冲的。这直接影响调用方是否会被阻塞：往无缓冲 channel 发送会等待接收方就绪；而缓冲满时也会阻塞。这种隐式依赖容易引发死锁。

实操建议：

• 函数文档必须明确说明对 channel 缓冲特性的假设（例如：“要求传入带缓冲的 channel，容量至少为 4”）
• 优先使用带缓冲 channel 作为参数，减少意外阻塞；容量根据典型吞吐预估，而非设为 1
• 若函数内部会大量写入，考虑加超时或 select default 分支，避免无限等待
• 测试时用不同缓冲配置（0、1、N）覆盖，验证行为一致性

实际写的时候最容易忽略的是方向声明和关闭权归属——这两个点一旦出错，问题往往在线上压测或高并发时才暴露，且堆栈信息不直观。