<p>Go编译器要求channel传参必须指定方向：不能将无方向的chan T直接传给只读（<-chan T）或只写（chan<- T）函数，否则报错“cannot use ch (type chan int) as type”。</p>
channel 传参必须指定方向
Go 编译器不允许把无方向的 chan T 直接传给只读或只写的函数，否则会报错 cannot use ch (type chan int) as type 。方向是类型的一部分，不是可选修饰。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 接收方只读数据，参数用
（只读通道） - 发送方只写数据，参数用
chan（只写通道） - 函数内部需双向操作（如关闭、判断是否关闭），才用
chan T，但要格外小心协程安全 - 调用方传入的原始通道可以隐式转换为更受限的方向类型，例如
chan int可传给func f(，反之不行
不要在函数内关闭传入的 channel
关闭一个已被其他 goroutine 使用的 chan 是危险操作，会导致 panic：panic: close of closed channel 或更隐蔽的竞态。Go 没有运行时检查谁“拥有”通道，但设计上应由 sender 侧统一管理生命周期。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 函数签名中若参数是
chan，说明该函数是 sender，可考虑关闭（但仍需确认是否真为唯一 sender） - 若参数是
，绝对不要调用 <code>close()—— 这属于越权 - 需要通知结束？用额外的
done 参数，而不是关 channel - 如果必须传递“可关闭的通道”，显式用
*chan T并文档注明所有权转移，但极不推荐
避免 channel 类型暴露在公共 API 中
把 chan T 放在导出函数签名里，等于把并发模型和生命周期管理强耦合进接口，后续难以替换为其他通信方式（如回调、事件总线、共享内存），也难做 mock 测试。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 对外暴露的函数尽量用普通参数 + callback 函数，例如
func Process(items []T, onItem func(T)) error - 内部实现可用 channel 调度，但对调用方透明
- 若必须用 channel（如流式处理 SDK），提供封装类型，比如
type ItemStream struct { ch ，隐藏底层 <code>chan类型 - 避免在结构体字段中直接存裸
chan，改用方法控制收发逻辑
func NewItemStream() *ItemStream {
ch := make(chan Item, 16)
return &ItemStream{ch: ch}
}
<p>func (s *ItemStream) Send(item Item) {
s.ch <- item
}</p><p>func (s *ItemStream) Output() <-chan Item {
return s.ch
}注意缓冲区大小与阻塞行为对调用方的影响
函数接收 chan T 时，无法得知它是带缓冲还是无缓冲的。这直接影响调用方是否会被阻塞：往无缓冲 channel 发送会等待接收方就绪；而缓冲满时也会阻塞。这种隐式依赖容易引发死锁。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 函数文档必须明确说明对 channel 缓冲特性的假设（例如：“要求传入带缓冲的 channel，容量至少为 4”）
- 优先使用带缓冲 channel 作为参数，减少意外阻塞；容量根据典型吞吐预估，而非设为 1
- 若函数内部会大量写入，考虑加超时或 select default 分支，避免无限等待
- 测试时用不同缓冲配置（0、1、N）覆盖，验证行为一致性
实际写的时候最容易忽略的是方向声明和关闭权归属——这两个点一旦出错，问题往往在线上压测或高并发时才暴露，且堆栈信息不直观。
