Go语言Channel引用传递解析

Go语言中的channel虽是引用类型，但其传参本质是复制指向底层结构的指针值，因此多个goroutine共享同一channel实例——关闭、发送或接收操作均全局可见；nil channel收发会永久阻塞而非panic，常用于select中动态禁用分支；传输指针还是值取决于数据大小与共享需求：小结构体传值更高效，大对象或含引用字段的类型宜传指针，但需注意指针传递带来的数据共享副作用；channel关闭后仍可读取剩余数据，但再次写入将panic，且逻辑上应由数据生产者负责关闭。理解这些机制，才能写出安全、高效、符合直觉的并发代码。

channel 是引用类型，但不是“引用传递”

Go 中的 chan 是引用类型，变量本身存储的是指向底层 runtime.hchan 结构的指针；赋值或传参时，复制的是这个指针值，而非整个队列数据。这意味着多个变量可共享同一个 channel 实例——你关掉它，所有地方都感知得到；往里发数据，任意接收方都能拿到。

• 误以为“传 channel 就像传 struct 一样拷贝全部状态”，结果发现关闭行为跨 goroutine 生效，一脸懵
• 函数参数写 func worker(c chan int)，和 func worker(c *chan int) 完全等价——后者是错的，chan 本身已含指针语义，再加 * 属于画蛇添足
• nil channel 的零值是 nil，对它收发会永久阻塞（不是 panic），常被用来在 select 中临时禁用某个分支

向 channel 发送指针 or 值？关键看所有权和逃逸成本

channel 传输的是值：哪怕你传 *T，也是把那个指针的值（即地址）拷贝一份过去。真正决定内存开销和共享行为的，是你发送的内容本身是否带指针、是否大对象。

• 小结构体（如 type Event struct{ ID int; Ts int64 }）直接传值更高效，避免额外解引用和 GC 压力
• 大结构体或含切片/映射的复合类型，传 *T 更合理——否则每次发送都在堆上分配副本，还可能触发逃逸分析失败
• 注意：若接收方修改了 *T 指向的数据，发送方也能看到——这不是 channel 的问题，是 Go 值传递中“指针值”天然带来的共享语义

close() 后还能读，但不能写：常见 panic 场景

关闭 channel 是单向操作，且只能由 sender 侧发起（虽语法不限制谁调，但逻辑上应由数据生产者负责）。一旦 close(ch)，再执行 ch 就会 panic：send on closed channel。

• 典型错误：多个 goroutine 并发往同一 channel 发数据，各自判断条件后都尝试 close → 第二次 close 直接 crash
• 安全做法：只由一个 goroutine（通常是主控或协调者）负责关闭；或用 sync.Once 包一层
• 读取已关闭 channel 不 panic：有缓存时读完缓存再返回零值+false；无缓存时立即返回零值+false
• x, ok := 中的 ok 是唯一可靠判断 channel 是否已关 + 空的方法，别依赖 len(ch) == 0（长度不可靠，尤其无缓冲 channel）

用 channel 实现同步时，最容易漏掉的不是逻辑，是等待机制

很多人用 channel 当信号量，比如启动 N 个 goroutine 处理任务，想等它们全结束再退出 main。最简方式是用一个 done chan struct{}，每个子 goroutine 结束时发一次 done ，main 用 for 循环收 N 次。

• 忘了用 for i := 0; i ，而是只写一次 → main 提前退出，子 goroutine 成为孤儿
• 没 close channel，也没设超时，万一某个 goroutine panic 或卡死，main 就永远卡在那条 上
• 更健壮的做法：配合 select + time.After 做兜底，或改用 sync.WaitGroup（它不依赖 channel，语义更清晰）

channel 的引用语义本身很干净，麻烦往往出在“谁该关、何时读、怎么等”这些协作契约上——它不强制你写对，只提供机制。写的时候多问一句：这个 channel 的生命周期，到底由谁定义？

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《Go语言Channel引用传递解析》文章吧，也可关注golang学习网公众号了解相关技术文章。