Go 中 channel 作为函数参数时本身不需要加锁
Go 的 channel 是并发安全的：向 channel 发送（ch ）和接收（）操作天然原子，底层由 runtime 用 mutex 保护。只要不把 channel 和其他非并发安全的数据（比如 map、slice、自定义 struct 字段）混在一起共享，单独传 channel 给多个 goroutine 用完全没问题。
常见误解是“既然多 goroutine 在用，就得加锁”，但这是把 channel 错当成普通变量了。它本质是个带同步语义的通信原语，不是需要手动保护的临界资源。
什么情况下你会误以为要给 channel 加锁？
典型场景是把 channel 和非并发安全状态耦合使用，比如：
- 用一个全局
map[string]chan int，但没保护 map 本身的读写 —— 这里要锁的是map，不是chan int - 在函数里对 channel 做了
close(ch)，同时其他 goroutine 还在发/收 —— 这属于逻辑错误（panic: send on closed channel），不是锁能解决的，得靠关闭协议（如用sync.Once或额外 done channel） - 把 channel 存在 struct 里，又让多个 goroutine 同时修改该 struct 的其他字段 —— 锁的是 struct，不是 channel 字段本身
传 channel 比传 slice/map 更省心，但要注意关闭时机
channel 的“并发安全”不等于“任意关闭都安全”。关键点在于：
- 只能 close 一次，且只能由 sender 关闭（receiver 关闭会 panic）
- 关闭后继续 send 会 panic；继续 recv 会得到零值 + false（ok=false）
- 如果函数接受
chan（只写）或（只读），编译器会帮你挡住非法操作，比裸指针安全得多
所以比起加锁，更该花精力设计 channel 生命周期：谁创建、谁关闭、是否需要 context.Context 控制退出。
真要加锁的，往往是 channel 背后的缓冲或状态管理
比如实现一个带缓冲池的 channel 工厂，内部维护 freeChans []*Channel 切片，这时对切片的 push/pop 就必须加 sync.Mutex —— 因为 []*Channel 本身不是并发安全的。
再比如封装 channel 的 wrapper struct：
type SafeChan struct { mu sync.RWMutex ch chan int closed bool }这个 mu 不是为了保护 ch 的收发，而是为了保护 closed 标志位和防止重复 close。真正发数据时，仍直接走 c.ch ，不经过锁。
复杂点往往不在 channel 本身，而在你试图用它去模拟队列、信号量或状态机时，悄悄混入了非并发安全的辅助数据结构。