go的chan底层基于hchan结构体，含锁、等待队列、环形缓冲区（有缓冲）或直接通信（无缓冲）；close后可读尽剩余数据再返回零值+false，写则panic；select+default非真正非阻塞写。
channel 底层用什么数据结构实现
Go 的 chan 不是简单封装的队列，而是基于环形缓冲区（有缓冲）或直接通信（无缓冲）的同步原语。核心结构体是 hchan，它包含锁 lock、等待队列 sendq/recvq、缓冲数组 buf 和长度/容量字段。
关键点：无缓冲 channel 的读写必须配对发生，靠 goroutine 挂起+唤醒完成同步；有缓冲 channel 才真正用到 buf 这块内存，但大小固定，不会扩容。
- 查看源码可定位到
src/runtime/chan.go中的hchan定义 -
buf是unsafe.Pointer类型，实际指向一段连续内存，类型由 make(chan T, N) 中的T决定 - 即使
len(buf) == 0（即无缓冲），buf字段也可能非 nil —— 这是早期版本遗留细节，现版本已优化，但面试时提一句更显扎实
close() 后还能读不能写，但读的行为分情况
关闭 channel 后，close() 只能调一次，重复 close 会 panic：panic: close of closed channel。读操作不会 panic，但返回零值 + ok==false；但如果缓冲区还有数据，仍能读出剩余值，直到读完才开始返回零值。
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 有缓冲 channel：
close(ch)后，仍可读取所有未被取走的元素，之后才返回(T{}, false) - 无缓冲 channel：
close(ch)后，任何立即返回 <code>(T{}, false) - 写操作在 close 后必 panic，哪怕 goroutine 正在阻塞等待接收 —— runtime 会在写入前检查
closed标志位
select + default 为什么不是“非阻塞 send”安全写法
很多人用 select { case ch 来避免 send 阻塞，但这只适用于「当前无人接收」的瞬时判断，不等于 channel 可写。如果 receiver 在 <code>select 判定后立刻退出，或缓冲区刚好满，该写操作仍可能永远阻塞在下一次尝试中。
- 真正安全的非阻塞写需配合
len(ch) （仅限有缓冲）或使用带超时的 <code>select+time.After -
default分支只是跳过当前 select，不代表 channel 状态稳定 —— 并发环境下，len/cap检查和后续 send 之间存在竞态窗口 - 常见误用：把
select { case ch 当作“尽力发送”，结果漏掉大量数据，因没处理 <code>default或没设超时
for range chan 什么时候退出
for range ch 本质是持续接收，直到 channel 关闭且缓冲区清空。它等价于：for { v, ok := 。所以退出条件非常明确：channel 已 close，且所有已入队元素都被读完。
- 如果 sender 早于 receiver 关闭 channel，receiver 能读完全部数据后退出
- 如果 sender 持续发数据却不关 channel，receiver 永远不会退出 —— 即使中间有
time.Sleep也不影响循环本身 - 注意：
range不感知 sender 是否还活着，只看 channel 的 closed 状态和 buf 是否为空
复杂点在于，很多人以为「sender goroutine 结束」就等于 channel 关闭，其实完全无关 —— 关闭动作必须显式调用 close()，否则 receiver 会一直等下去。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
