快手PHP架构组Swoole面试聚焦三大真实痛点：协程变量污染（static不隔离，须用Channel或Co::getuid()隔离）、连接池误用（min_connections=4/max_connections=32等参数失配致QPS腰斩）、热更新失效（reload不刷新OPcache和类定义，需SIGUSR2全量重启）。
快手 PHP 架构组在 Swoole 相关面试中，不考概念背诵，只盯三个真实痛点：协程变量污染、连接池误用、热更新失效。你写出来的代码，必须能在他们的高并发直播字幕服务里跑通。
协程内不能直接用全局静态变量或单例
现象：你在 onReceive 里 new 了一个 LiveCaptionService，里面存了 private static $cache = []，结果两个并发请求拿到的 cache 是混的。
原因：Swoole 的 Worker 进程常驻，协程间共享同一份静态内存空间，static 变量不是协程隔离的。
- 改用
Co\Channel或Co\WaitGroup做协程局部状态传递 - 数据库/Redis 客户端必须用
Swoole\Coroutine\MySQL或co\Redis，它们内部已做协程上下文隔离 - 若必须缓存，用
Co::getuid()作为 key 前缀，手动隔离协程作用域
连接池配置错一个参数，QPS 直接腰斩
现象：用 think-swoole 配了 MySQL 连接池，压测发现每秒只能撑 200 请求，而同样 SQL 在 CLI 下能到 1500+。
立即学习“PHP免费学习笔记（深入）”；
关键参数差异：
-
max_idle_time设太大（如 60s），空闲连接积压，新请求抢不到连接 -
min_connections设为 0，冷启动时每个请求都要新建连接，首字节延迟飙升 - 没配
timeout，某个慢查询卡住整个连接池，后续请求全排队等待
快手线上典型值：min_connections=4、max_connections=32、max_idle_time=10、timeout=1.5（单位秒）
修改代码后 reload 不生效？别急着 kill -USR1
现象：改完 onMessage 回调逻辑，执行 php think swoole restart，但新逻辑没跑，还是旧的。
根本原因：Swoole 的 reload 只重启 Worker 进程，但以下两类资源不会被重载：
- 已加载的 Composer 类定义（
class_exists()返回 true 就不会重新 require） - PHP OPcache 缓存的脚本字节码（尤其开启
opcache.validate_timestamps=0时）
实操方案：
- 开发期强制关闭 OPcache：
opcache.enable=0+opcache.validate_timestamps=1 - 类文件变更后，加一行
opcache_invalidate(__FILE__, true)在文件末尾（仅调试用） - 上线必须用
kill -SIGUSR2全量重启 Master，而不是 reload
快手字幕服务的真实约束比文档写的更硬：协程生命周期必须严格对齐单次 pull 请求，连接池 timeout 必须小于快手接口的 3000ms 硬限制，任何未显式 Co::sleep() 的阻塞调用都会让整个 Worker 卡死——这些不是理论，是他们线上告警日志里反复出现的根因。
