用 struct{} 做 channel 元素因零内存开销且语义清晰，仅表示“通知到达”；它可正常 close，不可与 interface{} 混用；单次通知宜用无缓冲 channel 配合 close()。
为什么用 struct{} 做 channel 元素？
因为零内存开销，且语义清晰：你只关心“通知到了”，不传任何数据。用 bool 或 int 都会多占 1–8 字节，而 struct{} 在 Go 里大小恒为 0，len(ch)、cap(ch) 行为也完全一致。
常见错误是误以为 chan struct{} 不能 close —— 它完全可以 close，而且这是标准做法；另一个坑是把 struct{} 和 interface{} 混用，后者有动态类型信息，不是零成本。
- 必须用
make(chan struct{}, N)指定缓冲区，否则默认无缓冲，发送会阻塞直到有人接收 - 若只用于单次通知（如服务启动完成），用无缓冲 channel +
close()更安全，接收方用_, ok := 判断是否已关闭 - 不要用
chan *struct{}—— 指针反而引入 GC 开销和 nil 风险，毫无必要
select 配合 struct{} channel 的超时控制怎么写？
这是最常被写错的场景：想等信号，但又不想无限卡住。关键点在于 select 中的 default 不等于“超时”，它只是非阻塞尝试；真超时得靠 time.After 或 time.NewTimer。
典型错误是写成 select { case —— 这其实根本没等，立刻走 default。
立即学习“go语言免费学习笔记（深入）”；
- 正确姿势是：
select { case - 如果
done是无缓冲 channel，且发送方还没发就进 select，那整个 select 会阻塞在上，直到超时或收到信号 - 注意
time.After每次调用都新建 timer，高频调用建议复用*time.Timer并调用Reset()
多个 goroutine 等待同一个 struct{} channel 会发生什么？
取决于 channel 类型：无缓冲 channel 只能唤醒一个接收者，其余继续等待；有缓冲 channel（如 make(chan struct{}, 10)）可让最多 10 个 goroutine 立即返回，超出数量的仍阻塞。
这不是 bug，是 Go channel 的确定性调度行为。容易踩的坑是以为 “发一次，全员唤醒” —— 实际上 Go 没有广播机制，close(ch) 才是唯一能让所有阻塞接收者立即返回的方式（返回零值 + ok=false）。
- 若需广播效果，统一用
close(ch)，而非反复 send；接收方检查ok即可 - 不要在循环里反复
send到无缓冲 channel 试图“唤醒所有人”，这会导致 panic（send to closed channel）或死锁 - 若要精确控制唤醒数量（比如只唤醒前 3 个 worker），必须自己加计数器或用 sync.WaitGroup 配合
和 sync.WaitGroup 或 sync.Once 比，chan struct{} 同步适合什么场景？
chan struct{} 的核心优势是**可组合、可 select、可带上下文取消**；WaitGroup 只适合“等全部完成”，Once 只保证“只执行一次”，它们都不支持超时、取消、或与其他 channel 联动。
比如 HTTP handler 里启动后台任务，既要等初始化完成，又要响应 ctx.Done() —— 这时混用 chan struct{} 和 context 最自然。
- 用
WaitGroup：适合主流程明确知道要等几个 goroutine，且不关心中间状态 - 用
chan struct{}：适合事件驱动逻辑，比如“配置加载完”“健康检查通过”“某资源就绪”，尤其需要 select 多路复用时 - 别为了“看起来更并发”强行替换 —— 如果只是初始化后执行一次，
Once更轻量，也不占 goroutine 调度资源
真正难的是判断该不该用 channel 做同步：它看似简单，但一旦涉及多个接收者、重用、或与 context 交织，边界就很容易模糊。多数人低估了 close 的语义重量——它不是“发个信号”，而是“这个 channel 彻底终结了”，后续任何 send 都 panic。这点比 buffer 大小或性能影响更值得盯紧。
