Hyperf的Redis操作并非天然协程安全，需确保底层PHP-Redis扩展被Swoole Hook或改用Swoole原生驱动；默认配置下rpop、brpop等命令仍可能同步阻塞，关键在验证Hook状态及正确配置连接池与驱动超时参数。
Hyperf的Redis操作真的协程安全吗？
不是所有Redis调用在Hyperf里都自动协程化。默认配置下，Redis::rpop、Redis::brpop 等命令仍可能触发同步阻塞，尤其当底层PHP-Redis扩展未启用协程支持时——Swoole不会自动接管原生扩展的socket读写，协程调度器对此类IO无感知。
检查Swoole是否已对Redis扩展协程化
关键不是“用了Hyperf”，而是底层PHP-Redis扩展是否被Swoole Hook。执行以下检查：
- 运行
php --ri redis，确认输出中包含redis.session.locking_enabled => 1（说明启用了会话锁，但不等于协程化） - 更直接的方式：在代码中调用
swoole_hook(SWOOLE_HOOK_ALL)后，再执行$redis->rpop('test')并观察是否仍阻塞；若阻塞，说明PHP-Redis扩展未被Hook - Hyperf 3.0+ 默认启用
SWOOLE_HOOK_REDIS，但仅对ext-redis的部分方法生效；rpop、lpop等列表操作不在默认Hook范围内
绕过Hook限制的实操方案
不依赖Swoole自动Hook，改用Hyperf原生支持的协程Redis客户端：
- 卸载
ext-redis，改用hyperf/redis+ext-swoole驱动（即基于Swoole\Coroutine\Redis） - 确保
config/autoload/redis.php中'driver' => 'swoole'（非'redis'） - 验证方式：在协程中并发执行10次
$redis->brpop('my_list', 1)，观察是否全部在1秒内返回（而非串行等待） - 注意：Swoole Redis驱动不支持
OPT_READ_TIMEOUT => -1，必须显式传超时值，否则默认为1秒
brpop超时设为0仍卡住？这是典型配置陷阱
很多人以为 $redis->brpop('key', 0) 是“永不超时”，但在Hyperf+Swoole组合下，这反而会退化成同步阻塞。原因在于：
- Swoole\Coroutine\Redis 的
brpop方法将timeout=0解释为“使用连接池默认读超时”，而该值由pool.read_timeout控制，默认是3.0 - 真正想实现“非阻塞轮询”，应改用
llen+rpop组合，并配合co::sleep(0.01)避免空转耗CPU - 若必须用阻塞式消费，推荐固定超时如
brpop('key', 5)，并捕获返回null做重试逻辑，而非依赖无限等待
最易被忽略的一点：Hyperf的Redis连接池配置（wait_timeout、max_idle_time）和Swoole Redis驱动的超时参数（read_timeout、write_timeout）是两套独立系统，改错地方就白调。
