channel是goroutine间通信的唯一推荐方式，无缓冲channel需收发同步，带缓冲channel可暂存数据；向已关闭channel发送会panic，接收则返回零值；select需default或阻塞操作，否则可能永久阻塞。
channel 是协程通信的唯一安全通道
Go 中没有共享内存式通信，channel 是 goroutine 之间传递数据的**唯一推荐方式**。直接读写全局变量或结构体字段会导致竞态（data race），即使加锁也违背 Go “通过通信共享内存” 的设计哲学。
使用 channel 时必须注意：它默认是阻塞的，发送和接收会互相等待；容量为 0（即无缓冲）时，收发必须同时就绪才能完成。
-
make(chan int)创建无缓冲 channel，适合同步信号（如“任务完成通知”） -
make(chan string, 10)创建带缓冲 channel，可暂存 10 个值，避免发送方立即阻塞 - 向已关闭的 channel 发送会 panic；从已关闭的 channel 接收会立即返回零值 +
false
select 多路复用必须配 default 或阻塞操作
select 不是轮询，而是 Go 运行时提供的**非阻塞多路等待机制**。如果所有 case 都不可达（例如所有 channel 都空且无 default），select 会永久阻塞——这是常见卡死原因。
典型误用：select 只有 recv 操作但没 default，而 sender 还没启动或延迟发送。
立即学习“go语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
ch := make(chan int)
// ❌ 卡死：ch 为空，又没 default
select {
case x := <-ch:
fmt.Println(x)
}
// ✅ 加 default 实现非阻塞尝试
select {
case x := <-ch:
fmt.Println("received:", x)
default:
fmt.Println("no data yet")
}超时控制必须用 time.After 或 context.WithTimeout
不能靠循环 + select + time.Sleep 实现超时，这会浪费 goroutine 和时间精度差。Go 标准做法是把 time.After(d) 当作一个只发一次的 channel 来参与 select。
-
time.After(3 * time.Second)返回<-chan time.Time，3 秒后自动发送当前时间 - 更健壮的做法是用
context.WithTimeout，尤其在涉及子 goroutine 传播取消信号时 - 注意：
time.After不可重用，每次超时需新建
ch := make(chan string, 1)
go func() {
time.Sleep(5 * time.Second)
ch <- "done"
}()
select {
case msg := <-ch:
fmt.Println(msg)
case <-time.After(2 * time.Second):
fmt.Println("timeout!")
}关闭 channel 前确保所有 sender 已退出
close() 只应由 sender 调用，且**只能关闭一次**。过早关闭会导致 receiver 收到零值并误判为有效数据；重复关闭 panic。
常见模式是用 sync.WaitGroup 等待所有 sender 完成后再关闭：
ch := make(chan int, 10)
var wg sync.WaitGroup
wg.Add(2)
go func() {
defer wg.Done()
for i := 0; i < 5; i++ {
ch <- i
}
}()
go func() {
defer wg.Done()
for i := 5; i < 10; i++ {
ch <- i
}
}()
go func() {
wg.Wait()
close(ch) // 所有 sender 结束后才关
}()
for v := range ch { // range 自动检测 closed
fmt.Println(v)
}真正难的是协调多个 sender 的生命周期，尤其是存在错误提前退出、或需要中途取消的情况——这时候得结合 context 和显式状态检查，不能只依赖 close。
