Go 的 channel 并非无锁——所有读写操作均受 runtime 内部 hchan.lock 保护，锁粒度为整个 hchan 结构体，有/无缓冲 channel 均使用同一把锁，高并发写仍串行化。
channel 操作真不加锁？别被“无锁”说法骗了
Go 的 channel 并非无锁——所有读写操作（send / recv）在 runtime 层都受 hchan.lock 保护。这个锁是 Go 运行时内部的 mutex，不是 sync.Mutex，但作用一样：防止多个 goroutine 同时修改 qcount、sendx、recvx 或等待队列指针导致数据错乱。
常见错误现象：fatal error: all goroutines are asleep - deadlock 有时表面看是逻辑卡死，实则是锁竞争未暴露，比如在 select 中误用 nil channel + 长时间阻塞，掩盖了底层锁已持有时序问题。
- 有缓冲和无缓冲 channel 都用同一把锁，区别只在是否立即阻塞，不改变并发安全模型
- 锁粒度是整个
hchan结构体，不是 buf 数组某一段——所以高并发写同一 channel 仍会串行化 - 不要试图绕过锁做“原子读写”，runtime 不保证
qcount等字段对外可见性；想查长度请用len(ch)（它本身也加锁）
hchan 结构里哪些字段影响你的实际行为
hchan 不是教学玩具，它的每个字段都在 runtime 中参与调度决策。你写的 make(chan int, 5)，直接映射到结构体的三个关键字段：dataqsiz（=5）、buf（堆上分配的 5×8 字节数组）、qcount（当前元素数，初始为 0）。
使用场景：当你观察到 goroutine 在 上卡住却没 panic，大概率是 <code>qcount == 0 且 recvq 为空，而发送方还没就位；若卡在 ch ，可能是 <code>qcount == dataqsiz 且 sendq 为空。
立即学习“go语言免费学习笔记（深入）”；
-
sendx和recvx是 uint 类型，从 0 开始递增，满后回绕——这就是环形缓冲区的全部实现，没有额外计算开销 -
closed是 uint32，用原子操作读写；close(ch)本质就是把它设为 1，并唤醒recvq全部 sudog -
elemtype和elemsize决定 runtime 能否正确拷贝数据；传*T时它们记录的是指针大小（8 字节），不是T本身大小
用 channel 传指针时，真正危险的不是 channel 本身
channel 可以安全传输 *T 类型，hchan 对指针和值一视同仁——它只管拷贝 8 字节地址。真正出问题的地方永远在「谁在什么时候改那块内存」。
常见错误现象：goroutine A 发送 &user 到 channel，goroutine B 接收后修改 user.Name，结果 A 中的 user 也变了，接着 A 又把 &user 发给另一个 channel —— 此时若 A 的栈帧已回收，B 持有的就是悬空指针。
- 栈变量取地址后传入 channel，必须确保接收方生命周期不长于发送方函数作用域（或显式逃逸）
- map/slice 指针尤其危险：它们底层数组可能被扩容重分配，原指针立刻失效
- 更安全的做法是封装命令（如
ConfigCmd），让单个 goroutine 独占持有原始数据，channel 只传操作意图
为什么不能靠看 hchan 源码来“优化”channel 使用
src/runtime/chan.go 里的 hchan 定义和 chansend/chanrecv 函数，是 runtime 内部契约，不是 API。它不承诺字段顺序、不保证未来版本兼容、也不开放给你直接访问。
性能影响：有人尝试用 unsafe 强转 chan 指针去读 qcount，看似省了锁，实则破坏内存模型，Go 1.22+ 已在部分平台触发 undefined behavior；GC 也可能因绕过类型系统而漏扫指针。
- 想测 channel 是否为空？用
len(ch) > 0，它比自己手撸 unsafe 更快更稳 - 想等 channel 关闭？用
val, ok := ，别轮询 <code>closed字段 - 调试时想看内部状态？
go tool trace或runtime.ReadMemStats更可靠，hchan 不是监控接口
最常被忽略的一点：hchan 的存在本身就是为了让你不用关心这些。你该纠结的是业务语义——谁生产、谁消费、背压怎么控、关闭时机在哪——而不是 buf 地址偏移几字节。
