Go 只接收 channel 的参数为什么不能调用 close

如果函数参数写成 ，函数体只能从这个通道接收数据，不能发送，也不能调用 close。这不是运行时权限不足，而是编译器根据参数的静态类型直接拒绝调用。真正应该关闭通道的一般是生产者：它确认后面不会再发送；消费者只读取数据，并通过结束信号收尾。

为什么

Go 的 channel 类型可以明确标注方向。双向的 chan int 同时拥有发送和接收能力；赋值给 后，得到的是一个只读视图。底层仍然是同一个 channel，但参数声明只向函数暴露接收能力。

close(ch) 的含义是记录“以后不会再向 ch 发送值”。因此它不是读取动作，而是改变通道生命周期的管理操作。规范明确规定：如果 close 的参数是接收专用通道，就是错误；向发送专用通道关闭则在类型上可行。

参数写成

方向转换只能收窄能力，不能从接收专用视图凭空恢复发送或关闭权限。下面的函数可以接收，但两处都会编译失败：

func consume(ch 

调用方手里如果还保留着原来的 chan int 变量，调用方仍可以关闭它；但函数内部的 ch 只是受限视图。不要尝试用类型转换“补回”权限，这会破坏函数签名想表达的责任边界。

把 close 放回发送方

一个实用的接口设计是：生产函数接收 chan，只向外发送并在发送结束后关闭；消费函数接收 ，只读取。这样编译器会帮助你防止消费者误发数据，也会让关闭责任清楚地落在生产者一侧。

func produce(out chan

如果多个 goroutine 都可能发送，就不能让它们各自随意 close。应由协调者等待所有发送者结束后统一关闭，否则重复关闭会触发运行时 panic。关闭 nil channel 也会 panic。

消费者如何判断 channel 已经关闭

只关心所有值并在结束时退出时，用 range 最简洁。若零值本身有业务含义，则使用双返回值接收，第二个值为 false 时才表示通道已关闭且没有更多数据：

func consumeOne(in 

关闭后，已经发送到缓冲区的值仍会先被读出；缓冲值读完后，接收立即得到元素类型的零值。这个语义也解释了为什么“接收方调用 close”不是结束读取的必要条件：消费者只需读完并识别 ok=false。

常见问题

发送专用的 chan 可以 close 吗？

可以，规范禁止的是接收专用 channel。是否应该关闭仍取决于它是不是唯一的发送责任方。

关闭 channel 后还能继续发送吗？

不能。向已关闭通道发送会触发运行时 panic；因此 close 必须发生在最后一次发送之后。

消费者可以关闭通道来通知生产者停止吗？

不建议。关闭是“不会再发送”的声明，消费者通常应通过另一个取消通道或 context.Context 发送停止请求，让生产者自行结束并关闭输出通道。

所以，看到 cannot close receive-only channel 时，先检查参数方向和职责设计：读取函数继续使用 ；需要发送并负责收尾的生产函数使用 chan 或 chan T，不要在接收方强行恢复权限。