能，channel是引用类型，传参时传递的是底层hchan指针，多个goroutine共享同一队列和锁；需由唯一发送方关闭且只关一次，接收方须用v, ok :=判断是否关闭。
Go 中 channel 能不能像普通变量一样传给其他 goroutine？
能，但必须理解它传的是“引用”还是“值”——channel 类型本身是引用类型，赋值或传参时传递的是底层 hchan 结构体的指针，不是拷贝。这意味着多个 goroutine 操作同一个 channel 实例，本质是在共享同一套发送/接收队列和锁。
常见错误现象：panic: send on closed channel 或死锁，往往是因为多个 goroutine 误以为自己“拥有”该 channel，擅自 close()；或者一个 goroutine 关闭后，另一个还在尝试接收却没做判断。
- 只要不显式
close()，多个 goroutine 安全地读写同一channel是 Go 的设计前提 - 关闭操作应由“唯一负责发送”的 goroutine 执行，且只关一次
- 接收方务必用
v, ok := 形式判断是否已关闭，不能只依赖 <code>
把 channel 当函数参数传进去，会不会意外复制？
不会。Go 中所有内置 channel 类型（chan T、chan、<code>）都是引用类型，传参、赋值、字段存储都只是复制指针。你可以把它类比为 <code>*os.File：改的是同一片内存里的状态。
使用场景：常用于构造“生产者-消费者”模式，比如启动 worker goroutine 时把 chan int 作为参数传入：
立即学习“go语言免费学习笔记（深入）”；
go worker(ch)
这里 ch 是原变量，worker 收到的是完全等价的引用，后续对它的读写直接影响原始 channel 状态。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 注意方向性：传
chan<- int进去，函数体内只能发不能收；传<-chan int则只能收不能发 - 方向转换需显式类型断言或重新声明，不能直接赋值（如
chan int→chan<- int合法，反过来不合法） - 结构体字段存 channel 也没问题，但要注意生命周期：若结构体被多次复制，channel 字段仍指向同一底层对象
为什么往 channel 发数据有时卡住，有时 panic？
卡住（goroutine 阻塞）和 panic（运行时错误）是两类不同问题，根源都在 channel 的状态和操作合法性上。
常见错误现象：
- 向
nilchannel 发送或接收 → 永久阻塞（因为nilchannel 永远不会就绪） - 向已关闭的 channel 发送 →
panic: send on closed channel - 从已关闭且无缓冲的 channel 接收完所有数据后继续接收 → 不 panic，返回零值 +
ok=false
性能影响：阻塞本身不消耗 CPU，但会让 goroutine 挂起等待调度器唤醒；而 panic 会终止当前 goroutine，若未 recover 可能导致整个程序崩溃。
- 初始化 channel 必须用
make(chan T)，避免传nil - 不要在多个 goroutine 中并发调用
close()，哪怕加了判断也容易竞态 - 如果需要“安全关闭”，推荐用
sync.Once包一层，或用额外的done chan struct{}控制生命周期
channel 和指针在内存模型里到底谁更“轻”？
channel 更重。一个 chan int 变量本身只占 8 字节（64 位系统下指针大小），但它的底层 hchan 结构体包含互斥锁、环形缓冲区指针、长度计数器等，实际分配在堆上，大小远超指针。
对比：一个 *int 就是纯指针，8 字节，不带任何同步逻辑；而 chan int 是带锁、带队列、带条件变量的完整并发原语。
- 别为了“省内存”把小数据塞进 channel 代替指针传递——除非你明确需要同步语义
- channel 的开销主要在首次
make分配和每次发送/接收的锁竞争上，不是变量本身 - 如果只是想让 goroutine 共享某个值，用指针 +
sync.Mutex或atomic更轻量；channel 应用于“解耦通信”而非“共享状态”
真正容易被忽略的是：channel 的关闭行为不可逆，且对所有持有该 channel 的 goroutine 立即可见。这点比指针复杂得多，也危险得多。
