解读

国内一线互联网公司在高并发网关、IM、实时推送等场景大量采用 Swoole/协程 PHP。面试官抛出“协程 ID 获取与上下文隔离方案”，核心想验证三点：

1. 是否真正用协程写过业务，而不仅停留在“听说”层面；
2. 对协程生命周期、调度器、内存模型的理解深度；
3. 能否给出可落地的“请求级”上下文隔离套路，避免数据污染、内存泄漏，并支持链路追踪、日志染色、灰度发布等运维需求。

若只回答“用 Co::getCid() 拿 ID”只能拿 60 分；必须补充“何时创建/销毁上下文”“如何透传”“异常安全”“性能权衡”才能拿到 90+。

知识点

1. Swoole 协程调度模型：C 级别栈切换，PHP 层无锁，单线程内多协程并发，cid 唯一且递增。
2. 协程生命周期钩子：onRequest/onWorkerStart 创建顶级协程，每次 IO 触发调度，协程退出时触发 defer 栈。
3. 上下文污染根因：PHP 超全局、static 变量、单例、连接池对象在协程间共享。
4. 上下文隔离手段：
   • 协程级存储：Co::getContext()/Co::getCid() 做 key 的 SplObjectStorage/WeakMap；
   • 请求级对象池：连接池采用“协程号 + 资源号”双 key 绑定，归还时检测 cid 防止交叉；
   • 值对象不可变：DTO、Entity 禁止 static 属性；
   • 日志/追踪：OpenTelemetry SDK 在协程创建时注入 trace-id，defer 中清理。
5. 性能权衡：Context 数组读写 O(1)，但频繁 new 数组仍增加 GC 压力；WeakMap 自动卸载，PHP≥8.0 推荐。
6. 异常安全：register_shutdown_function 在协程栈内不触发，需依赖 defer 或 try/finally。
7. 版本差异：Swoole<4.5 无 Co::getContext()，需自行维护 Co\Context 类；PHP8 协程栈默认 8k，可调整 co.stack_size。

答案

“我曾在广告竞价引擎中落地 Swoole 协程，峰值 80 wqps，单台 16 核维持 120 万协程。我们的上下文隔离方案分四层：

1. 入口统一封装
   在 onRequest 回调首行即 $cid = Co::getCid(); 取出协程 ID，同时生成 RequestContext 对象（含 trace-id、uid、实验标签）。将该对象写入 Co::getContext() 返回的数组，保证同一协程内随处可 $ctx = Co::getContext(); 拿到，避免全局数组污染。

2. 资源层绑定 cid
   连接池获取逻辑：$key = sprintf("%d_%s", Co::getCid(), $resourceName); 从池子里取私有连接，归还时校验 $conn->cid === Co::getCid()，若不一致直接抛 RuntimeException，杜绝交叉复用。

3. 业务层不可变对象
   所有 Service 入参使用 DTO，禁止 static 属性；容器级单例改为“协程级单例”，利用 SplObjectStorage 以 RequestContext 为 key，实现协程内共享、协程间隔离。

4. 生命周期清理
   在请求处理函数末尾注册 defer(function () use ($cid) { unset(Co::getContext()[$cid]); }); 即使逻辑异常退出，也能保证上下文及时释放，防止内存泄漏。
   上线后观察，worker 内存占用稳定在 130 MB，Full GC 次数下降 92%，慢查询 Trace 完整率 100%。”

拓展思考

1. 如果未来升级至 Swow 或 Fiber 原生协程，如何保持接口不变？
   答：把 Co::getCid() 封装进 Coroutine::id()，底层适配器根据运行时返回 Fiber::getCurrent() 的 object hash，实现零业务改造。

2. 上下文过大导致 GC 压力，如何进一步优化？
   答：采用 copy-on-write 数组，仅在写入时 clone；或引入线程本地存储（TLS）扩展，把超大只读配置放到共享内存，协程级只保留指针。

3. 多进程模式下，如何跨 worker 传递上下文？
   答：把 trace-id 写入 Redis/消息队列，下游 worker 在 onPipeMessage 中重建轻量级上下文；避免直接序列化整个 Context，防止数据膨胀。

4. 与 OpenSwoole 版本差异及商业化风险？
   答：国内云厂商镜像已同步 OpenSwoole 4.12，但 API 与 Swoole 5 有细微差异，需在 CI 层跑双引擎测试，防止锁版本带来的维护债。