Go语言中无内置屏障类型，可用通道配合WaitGroup实现一次性屏障，或用sync.Cond实现可重用屏障，亦可用原子计数+关闭通道模拟轻量级屏障；纯通道因缺乏广播和状态感知能力难以单独实现完整屏障。
Go语言中没有内置的同步屏障（Barrier）类型，但可以用通道（channel）配合其他同步原语实现“多个goroutine在某一点齐步走”的效果。关键在于：通道本身不直接提供屏障语义，需结合计数、信号传递和重用逻辑来构造。
用无缓冲通道 + WaitGroup 实现一次性屏障
适合只运行一轮的场景，比如初始化阶段等待所有配置加载完成再启动服务。
- 主协程调用 wg.Add(n) 预设参与协程数量，必须在启动 goroutine 前完成
- 每个协程执行到屏障点后调用 wg.Done()（建议用
defer确保执行） - 主协程在屏障点调用 wg.Wait()，阻塞直到全部 Done
- 注意：WaitGroup 不是真正的“到达即停”，它只等结束；若需严格控制“都在某行代码前暂停”，此方式不适用
用通道 + sync.Cond 实现可重用屏障
这是最贴近 Java CyclicBarrier 或 Python threading.Barrier 的做法，支持多轮等待。
- 内部维护一个计数器（用
sync.Mutex保护）和一个sync.Cond - 每个协程调用 Wait() 时先加锁、计数，若非最后一个则
cond.Wait()挂起 - 最后一个协程负责重置计数器并调用 cond.Broadcast() 唤醒全部等待者
- 必须用
Broadcast()而非Signal()，否则只能唤醒一个协程 - 唤醒后所有协程需重新获取锁、检查状态，避免虚假唤醒
用通道组合模拟轻量级屏障（无锁）
适用于低频、小规模、对延迟敏感的场景，避免锁开销，但会轻微占用 CPU。
立即学习“go语言免费学习笔记（深入）”；
- 定义一个
chan struct{}作为“放行信号通道”，初始为 nil - 每个协程到达屏障点后，向一个原子计数器加 1，并检查是否达到阈值
- 最后一个协程创建新通道、发送一次信号、关闭通道；其余协程循环接收该通道信号
- 因 Go 中从已关闭通道接收立即返回零值，可借此判断是否已被放行
- 注意：不能依赖
time.Sleep轮询，应结合select+default防止忙等
为什么纯通道难以单独实现完整屏障
无缓冲通道本质是两个协程间的同步点，无法天然支持“N选一”广播或“到达即停”的集体行为。
- 单个通道只能让两个协程配对通信，N 个协程需 N−1 次配对，逻辑复杂且易出错
- 通道关闭后所有接收者立即解阻塞，但无法区分“谁触发关闭”或“是否全员就绪”
- 若尝试用多个通道做扇出/扇入，会引入额外 goroutine 和内存开销，违背简洁初衷
- 因此生产环境推荐
sync.Cond封装，或接受 WaitGroup 的语义边界——它虽不是严格屏障，但足够可靠
