channel是引用类型，传参时复制指针值而非底层数据，故关闭或发送操作对所有引用者可见；nil channel收发会永久阻塞；传输指针或值取决于性能与共享需求，close后可读不可写。
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：<code>send on closed channel。
- 典型错误：多个 goroutine 并发往同一 channel 发数据，各自判断条件后都尝试
close→ 第二次close直接 crash - 安全做法：只由一个 goroutine（通常是主控或协调者）负责关闭；或用
sync.Once包一层 - 读取已关闭 channel 不 panic：有缓存时读完缓存再返回零值+
false；无缓存时立即返回零值+false x, ok := 中的 <code>ok是唯一可靠判断 channel 是否已关 + 空的方法，别依赖len(ch) == 0（长度不可靠，尤其无缓冲 channel）
用 channel 实现同步时，最容易漏掉的不是逻辑，是等待机制
很多人用 channel 当信号量，比如启动 N 个 goroutine 处理任务，想等它们全结束再退出 main。最简方式是用一个 done chan struct{}，每个子 goroutine 结束时发一次 done ，main 用 for 循环收 N 次。
立即学习“go语言免费学习笔记（深入）”；
- 忘了用
for i := 0; i ，而是只写一次 <code> → main 提前退出，子 goroutine 成为孤儿 - 没 close channel，也没设超时，万一某个 goroutine panic 或卡死，main 就永远卡在那条
上 - 更健壮的做法：配合
select+time.After做兜底，或改用sync.WaitGroup（它不依赖 channel，语义更清晰）
channel 的引用语义本身很干净，麻烦往往出在“谁该关、何时读、怎么等”这些协作契约上——它不强制你写对，只提供机制。写的时候多问一句：这个 channel 的生命周期，到底由谁定义？
