Go语言无法仅用单个chan struct{}实现可重用屏障，因无缓冲通道仅支持两两配对阻塞，有缓冲通道无法识别最后到达者，且close()会立即唤醒所有接收者而无法确保全员已抵达。
Go 语言没有内置的 Barrier 类型，纯用通道（chan）无法直接实现可重用、多轮等待的同步屏障——因为通道本身不支持广播唤醒或状态重置，必须配合其他原语才能可靠工作。
为什么不能只用一个 chan struct{} 实现屏障
无缓冲通道只能配对阻塞两个 goroutine；有缓冲通道又无法感知“谁是最后一个到达者”。常见错误是让每个 goroutine 向同一通道发信号，主协程接收 N 次，但这只是“等待完成”，不是“齐步走”：各 goroutine 到达屏障点的时间不同，有的早到早等，有的晚到晚进，彼此之间没有同步锚点。
- 若用
close(ch)当作放行信号，所有接收者会立即解阻塞，但无法保证“全员已抵达”——可能有人还没执行到就被唤醒了 - 若用
select+default轮询，会空转消耗 CPU，且仍无法判断是否全员就绪 - 多个 goroutine 同时向同一通道发送，需额外逻辑区分“计数”和“触发”，通道本身不提供原子计数能力
用 sync.WaitGroup + 通道做一次性屏障
适合初始化阶段等“只跑一轮”的场景，比如加载配置、预热缓存后统一启动服务。核心是把 WaitGroup 当计数器，通道当通知信道。
- 主 goroutine 调用
wg.Add(n)必须在go启动前完成，否则竞态 - 每个工作 goroutine 在屏障点调用
wg.Done()（建议defer确保执行） - 主 goroutine 在屏障点调用
wg.Wait()，阻塞直到全部Done - 如果还需传递结果或错误，可额外配一个带缓冲的
chan error或chan Result，由各 goroutine 发送
示例关键片段：
立即学习“go语言免费学习笔记（深入）”；
var wg sync.WaitGroup
done := make(chan struct{})
for i := 0; i < 3; i++ {
wg.Add(1)
go func() {
defer wg.Done()
// ... 执行任务
<-done // 等待放行（可选，用于控制第二阶段）
}()
}
wg.Wait() // 所有 goroutine 已抵达第一道屏障
close(done) // 放行
用 sync.Cond 实现可重用屏障
这是最接近 Java CyclicBarrier 的做法，支持多轮等待，底层依赖互斥锁 + 条件变量。通道在这里仅作为辅助信号载体（比如通知某轮结束），真正的协调靠 Cond。
- 内部用
sync.Mutex保护计数器，每次Wait()先加锁、递增、判断是否为最后一个 - 非最后一个调用
cond.Wait()，自动释放锁并挂起；最后一个调用cond.Broadcast()唤醒全部 - 必须用
Broadcast()，Signal()只唤醒一个，会导致其余 goroutine 永久阻塞 - 唤醒后所有 goroutine 会重新抢锁、检查条件，避免虚假唤醒
注意：不要试图用通道替代 Cond 的等待/唤醒逻辑——通道没有“等待某个条件成立”的语义，只有“收发数据”。
容易被忽略的关键点
屏障的本质不是“等全部结束”，而是“确保所有 goroutine 都停在同一个逻辑位置，再一起往下走”。这意味着：即使用了 WaitGroup，若某个 goroutine 在 wg.Done() 后还做了耗时操作，它其实已经“越障”了；而用 Cond 时，Wait() 返回后才真正算跨过屏障——这个时间点才是齐步的起点。实际编码中，最容易出错的是混淆“到达屏障”和“通过屏障”，把计数逻辑和业务逻辑耦合太紧，导致时序失控。
