hchan结构体中buf、dataqsiz、sendx、recvx、qcount五个字段协同模拟环形缓冲区：buf为底层数组指针，dataqsiz为容量，sendx/recvx为回绕游标，qcount记录实际元素数以避免模运算。
hchan 结构体里哪几个字段模拟环形缓冲区
Go 的 channel 缓冲区不是靠特殊内存布局实现的，而是用五个字段协同模拟出来的环形行为： buf、dataqsiz、sendx、recvx、qcount。
其中：buf 是堆上一段连续内存（本质就是普通数组指针），dataqsiz 是它的容量（即 make(chan int, N) 的 N）；sendx 和 recvx 是两个游标，取值范围始终在 [0, dataqsiz) 内，写满后自动回绕到 0；qcount 记录当前真实元素个数，避免每次都要做模运算来判断空/满。
- 不依赖
(sendx - recvx) % dataqsiz判空满 —— 因为负数模运算开销大，且边界难处理 -
sendx == recvx不能直接代表空或满，必须结合qcount == 0或qcount == dataqsiz才能准确判断 - 如果只看游标不动，容易误以为“缓冲区卡住了”，其实是
qcount已满/空，而游标只是位置指示器
无缓冲 channel 为什么必须 goroutine 配对才能不阻塞
无缓冲 channel 的 dataqsiz == 0，意味着 buf == nil，所有数据都走“直接通信”路径 —— 发送方必须等到有接收方在 recvq 里等着，才能把数据交过去；反之亦然。
- 单个 goroutine 执行
ch 后会立刻挂起，进入 <code>sendq等待，直到另一个 goroutine 执行<-ch唤醒它 - 若两个操作都在同一个 goroutine 里（比如先 send 再 recv），会死锁：goroutine 自己把自己卡住，没人唤醒自己
- 编译期不会报错，但运行时 panic 提示
fatal error: all goroutines are asleep - deadlock!
channel 关闭后读写行为差异
closed 字段是 uint32 类型的标志位，关闭动作本质就是把它从 0 改成 1。但它对读写的影响完全不同：
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
- 向已关闭的 channel 发送数据会 panic：
panic: send on closed channel - 从已关闭的 channel 接收数据不会 panic，而是立即返回零值 +
ok == false（如v, ok := <-ch中ok为 false） - 关闭一个
nilchannel 也会 panic：panic: close of nil channel - 重复关闭同一 channel 同样 panic：
panic: close of closed channel
select 处理多个 channel 时的随机性与公平性
select 在多个可就绪 case 间是伪随机选择的，不是按代码顺序，也不是按 channel 就绪先后 —— 这是 Go runtime 故意设计的，防止某个 case 总被优先选中导致饥饿。
- 即使
ch1和ch2同时有数据可读，select每次运行可能选不同分支 - 没有内置机制保证“轮询”或“优先级”，若需确定性顺序，得手动加锁或用其他同步原语
- 如果某个 case 对应的是
nilchannel，该分支永远不可就绪（相当于被忽略），但不会 panic - 带
default的select是非阻塞的，适合做“尝试发送/接收”场景，但要注意它可能抢在真实数据到达前执行
真正容易被忽略的是：hchan 的锁（lock）保护的是整个结构体，包括 sendq/recvq 队列操作和游标更新 —— 所以并发读写同一个 channel 不会破坏内部状态，但也不能假设多个 goroutine 同时发/收会有可预测的顺序。
