select 中的 channel 变量是已声明的 channel 实例，select 仅监听其收发操作；channel 本身是引用类型，但 select 不传递值，只等待就绪的通信。
select 里的 channel 变量到底传的是什么
channel 在 go 里确实是引用类型，但 select 语句本身不“传”任何东西——它只是监听一组已存在的 channel 操作。你写 case v := 或 <code>case ch ，<code>ch 是个变量，它的值是 runtime 内部的 hchan* 指针（底层 C 结构体指针），所以多个 goroutine 对同一个 ch 变量做 select，监听的是同一片内存地址上的通道状态。
为什么两个 goroutine select 同一个 channel 会互相影响
因为它们操作的是同一个通信媒介实例。不是“共享变量”，而是“共享底层队列、锁、等待队列”。比如一个 goroutine 在 select 中阻塞在 ，另一个 goroutine 此时往 <code>ch 发送数据，前者立刻被唤醒——这是由 runtime 的 waitq 和 lock 机制保证的，和“引用类型”这个语言层面的归类有关，但真正起作用的是运行时对那个 hchan 实例的统一调度。
- 常见错误现象：
select非阻塞尝试（default分支）没触发，但 channel 看似“空”，其实是因其他 goroutine 正在竞争读/写，导致状态瞬时不可见 - 使用场景：worker pool 中多个 worker goroutine 共用一个
jobs chan Job，每个都select监听该 channel，天然支持负载分发 - 参数差异：无显式参数；但 channel 的缓冲区大小（
make(chan int, 10)）直接影响select是否立即就绪——满 buffer 的 send、空 buffer 的 recv 都会阻塞
把 channel 当参数传进函数后在 select 里用，还共享吗
共享。只要传的是同一个 channel 变量（或它的副本），底层指向的仍是同一个 hchan 实例。Go 的 channel 变量赋值、函数传参、结构体字段存储，全都是复制指针值，不是深拷贝。
- 容易踩的坑：
ch := make(chan int); go f(ch); go f(ch)—— 安全；但go f(make(chan int))调用两次，就是两个独立 channel，互不影响 - 性能影响：无额外开销；
select的复杂度取决于 case 数量（O(n)），和 channel 是否共享无关 - 兼容性影响：从 Go 1.0 到现在，channel 的引用语义从未变过，所有版本行为一致
nil channel 在 select 中的特殊行为
nil channel 在 select 中永远不就绪——case 永远阻塞（除非有 <code>default），case nil 同样永久阻塞。这是 runtime 的硬编码逻辑，用来实现“动态停用某个分支”。
立即学习“go语言免费学习笔记（深入）”；
- 常见错误现象：channel 变量未初始化（值为
nil）就直接放进select，结果整个select卡死，且无 panic - 使用场景：用
if cond { ch = realChan } else { ch = nil }控制某条路径是否参与调度，比用布尔条件包裹整个case更干净 - 注意：
nil是 channel 变量的零值，不是“空 channel”；make(chan int, 0)是有效 channel，只是无缓冲
实际写的时候，别纠结“引用类型”这个标签，盯住一点：只要两个地方用的是同一个 channel 变量（哪怕经过多次赋值或传参），它们就在争同一个队列和锁。真正的复杂点从来不在类型系统，而在你有没有意识到：那个 ch 变量背后，是个带 mutex、waitq、buffer 的完整运行时对象。