不是 bug，而是 Swoole 协程调度器主动复用 ID 的设计行为；协程 ID 是轻量级任务槽位编号，用于高效调度，非单调递增序列号，不可用作请求唯一标识或顺序判断依据。
Hyperf 中 Co::getcid() 返回的协程 ID 不递增，不是 bug，而是 Swoole 协程调度器主动复用 ID 的设计行为 —— 它本质是轻量级任务槽位编号，不是单调递增计数器。
协程 ID 是槽位编号，不是序列号
Swoole 的协程 ID（CID）由底层协程调度器分配，它对应的是当前 Worker 进程内一个「协程执行槽位」的索引。当协程结束（如函数返回、协程退出），该槽位被释放，下次新协程启动时会优先复用最小可用 ID，而非无限制递增。
- 现象示例：连续发起 3 个请求，
Co::getcid()可能输出1→2→1（第三个请求复用了第一个已退出协程的槽位） - 原因：避免 CID 溢出（int32 范围有限）、减少内存索引表大小、提升调度器查找效率
- 影响：不能用 CID 做请求唯一标识、不能依赖其顺序性做逻辑判断（比如“CID 大的一定后启动”）
为什么 Hyperf 日志里 CID 看起来“乱跳”
在高并发或短生命周期协程场景下（如简单 HTTP 接口、空 handler），协程创建→执行→退出极快，CID 复用频率显著升高。配合 Hyperf 默认启用的协程上下文自动清理机制（Context::set() 绑定的数据在协程退出时自动销毁），你会观察到：
- 同一接口多次调用，
Co::getcid()输出可能是1、3、1、2—— 并非随机，而是取决于当时哪些槽位空闲 - 若在协程中起了子协程（
go()），子协程 CID 一定大于父协程，但子协程退出后，其 CID 仍会被后续新协程复用 - 使用
Parallel或Channel时，内部大量短协程密集启停，CID 波动更明显
哪些地方误用 CID 会导致问题
CID 仅适合做「当前协程内临时标记」，一旦跨协程、跨生命周期使用，必然出错：
- ❌ 把 CID 存进 Redis 作为用户会话 key：不同请求可能拿到相同 CID，覆盖彼此数据
- ❌ 在
onClose回调里查 CID 判断谁断开了：此时协程已销毁，Co::getcid()返回 0 或无效值 - ❌ 用 CID 做日志 trace_id 基础：必须配合
Context::get('trace_id', Str::uuid())生成真正唯一 ID - ✅ 正确用途：调试时快速定位当前执行路径（如
log->debug("in cid {$cid}");），或协程局部缓存键前缀（"cache:{$cid}:user"）
真正需要唯一性和可追溯性的场景，必须用业务层生成的标识（如请求 ID、用户 UID、UUID），而不是依赖底层调度器的槽位编号。协程 ID 的复用性恰恰说明了它的轻量本质 —— 它是系统高效运转的齿轮，不是你该刻字留念的碑石。
