Barrier是协程同步中专用于“全部到达后同时解除阻塞”的原语，不关心顺序、返回值或个体状态，与WaitGroup（关注完成计数）、Channel（关注数据传递）解决不同维度问题。
Barrier 不是协程同步的“替代品”，而是协程同步中一种特定语义的实现方式：它只关心“全部到达”，不关心顺序、返回值或谁先谁后。
Barrier 和普通协程同步（如 WaitGroup / Channel）的核心差异
很多人误以为 Barrier 是 WaitGroup 的简化版，其实它们解决的问题维度不同：
-
WaitGroup关注“计数”和“完成通知”，适合需要知道每个子任务是否成功、或需按顺序收集结果的场景； -
Channel关注“数据传递”和“流控”，适合有明确生产者-消费者关系、需跨协程传值的场景； -
Barrier只做一件事：所有协程调用一次wait()后，全部同时解除阻塞——它不记录谁完成了、没完成、返回了什么，甚至不暴露“当前还剩几个没到”。
Barrier::wait() 为什么必须在协程内调用
因为 Barrier::wait() 底层依赖 PHP 引用计数 + 协程挂起机制。一旦在非协程环境（比如主进程线程）中调用，会直接阻塞整个进程，而不是挂起当前协程。
Swoole 6.1.1
下载
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
- 常见错误：在
onWorkerStart回调里直接Barrier::wait($barrier)→ 进程卡死； - 正确做法：确保
wait()总是在Coroutine::create()或run()内部调用； - Workerman 中还需注意：
$worker->eventLoop必须设为Swoole::class或Swow::class，否则Barrier无法识别驱动类型而报错。
Barrier 创建与销毁的引用计数陷阱
Barrier 的生命周期靠 PHP 引用计数自动管理，但这个机制容易被忽略导致死锁或提前释放：
- 子协程必须用
use($barrier)显式捕获屏障对象，否则引用计数不增加，wait()会立刻返回； - 主协程也要持有
$barrier引用，否则在所有子协程退出前，屏障对象就可能被析构； - 不要手动
unset($barrier)—— 这会提前减引用，造成部分协程永远等不到释放。
Barrier 在 Swoole v6.2+ 中的实际兼容性注意点
虽然文档说 Barrier 支持 Swoole/Swow/Fiber 多驱动，但在 Swoole v6.2 实际使用中仍有细节差异：
- 若启用
Runtime::enableCoroutine(SWOOLE_HOOK_ALL)，Barrier::wait()行为稳定； - 若只 hook 部分函数（如仅
SWOOLE_HOOK_STREAM），Barrier可能无法正确感知协程退出，导致超时或假死； - Hyperf 用户注意：
Hyperf\Coroutine\Barrier是封装层，底层仍走 Swoole 的Swoole\Coroutine\Barrier，但默认 timeout 是 -1（无限等待），线上务必显式传入$timeout参数防雪崩。
真正容易出问题的地方不在写法，而在“谁该 hold 住 barrier 引用”——主协程、子协程、回调闭包，三者缺一不可，漏一个就可能让 wait 永远不返回。
