用 chan struct{} 传信号最轻量，因 struct{} 零大小、零开销；避免用 chan bool/int 传 true/1，以防语义误解和 GC 压力，且易在 select 中因缺 default 导致阻塞。
用 chan struct{} 做信号通知最轻量
Go 里传信号，别传数据，传“有”或“无”就够了。struct{} 零大小、零开销，比 chan bool 或 chan int 更干净。传 true 或数字反而浪费内存和 GC 压力。
常见错误是误用 chan int 发个 1 当信号——这会让人误以为数值有意义，也容易在 select 里漏掉默认分支导致阻塞。
- 初始化：
c := make(chan struct{}) - 发信号：
c （不能简写成 <code>c ） - 收信号：
（接收后值被丢弃，只关心是否收到） - 带超时收信号：用
select+time.After，避免永久阻塞
select 里收信号必须配 default 或 timeout
channel 是同步的，没人发， 就卡住。直接写 <code>if 在 goroutine 里看似简单，但一旦 <code>done 永远不关闭，整个 goroutine 就泄漏了。
典型场景是监听退出信号，比如 HTTP server 关闭、worker 停止。这时候你得确保逻辑能继续跑下去，或者明确放弃。
立即学习“go语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 非阻塞检查：
select { case - 带超时等待：
select { case - 永远别在循环外单独写
，除非你确定它一定会被关闭
close(c) 是通知“不会再有信号”，不是“发一个信号”
这是最容易混淆的点。很多人以为 close(c) 能让所有 立刻返回，其实不是：<code>close 后再读 channel 会立刻返回零值（对 struct{} 就是空结构体），但前提是还没读过。如果之前就阻塞在 上，<code>close 才会唤醒它。
更关键的是：关闭已关闭的 channel 会 panic；向已关闭的 channel 发送会 panic；但向已关闭的 channel 接收不会 panic，只是立即返回。
- 正确做法：只由发送方（或协调者）调用
close(c)，且只调一次 - 接收方不要假设
close= “我该退出了”，而要结合业务逻辑判断是否终止 - 用
select+ok := 可以检测 channel 是否已关闭（<code>ok == false），但struct{}本身没值，所以主要靠是否能读到
context.WithCancel 比裸 channel 更适合跨层取消
单个 goroutine 之间用 chan struct{} 完全够用；但一旦涉及父子 goroutine、多层调用、超时/截止时间、或需要同时通知多个 receiver，裸 channel 就难维护了。
比如一个 handler 启动了 3 个子 goroutine，你想统一停止它们——用 3 个独立 done channel 很麻烦，还要 close 多次；而 context.Context 天然支持树状传播和一次 cancel。
-
ctx, cancel := context.WithCancel(context.Background())，然后把ctx传给所有子 goroutine - 子 goroutine 用
select { case 监听 - 主 goroutine 调
cancel()即可批量唤醒 - 注意：不要把
cancel函数传给不可信代码，它可能被误调用
真正难的不是发信号，而是决定“谁关 channel”“什么时候关”“关完之后状态怎么清理”。这些没法靠语法解决，得看具体控制流。裸 channel 简单，但 context 更健壮；选哪个，取决于你的 goroutine 是否存在生命周期嵌套。
