hyperf 3.1中redis连接池未生效或配置不合理会导致缓存响应慢、频繁超时；需通过di:debug --tag=redis验证redispoolfactory是否存在，确保min_connections≥20、max_idle_time=30、启用health_check=true，并按数据特性分级设置缓存策略与序列化方式。
Hyperf 3.1项目中缓存响应慢、Redis连接频繁超时或新建连接耗时高，说明缓存策略设计不合理或连接池配置未适配业务压力。
确认当前Redis连接池是否生效
进入项目根目录，执行 php bin/hyperf.php di:debug --tag=redis，观察输出中是否存在 Hyperf\Redis\Pool\RedisPoolFactory 实例及其绑定的连接池配置项。
若无任何 RedisPoolFactory 输出，说明 Redis 组件未正确加载——检查 config/autoload/dependencies.php 中是否注册了 RedisFactory::class，且未被其他依赖覆盖。
若输出显示 pool 名为 default 但 min_connections 为 0 或 max_connections 小于 5，【该配置会导致高并发下连接争抢，请求排队等待】，必须调整。
修改连接池最小连接数与空闲回收策略
打开 config/autoload/redis.php，定位到 'pool' => [ ... ] 配置块。
将 'min_connections' => 5 改为 'min_connections' => 20：避免突发流量到来时频繁创建新连接，减少 TCP 握手和认证开销。
将 'max_idle_time' => 60（单位秒）改为 'max_idle_time' => 30：缩短空闲连接保活时间，防止大量长连接占用服务端资源却无实际复用。
注意：若业务 QPS 稳定在 300 以上，【min_connections 必须 ≥ 平均并发连接数 × 1.5】，否则连接池会持续扩容收缩，引发性能抖动。
启用连接池健康检测与自动重建
在 config/autoload/redis.php 的 pool 配置内，添加以下字段：
'health_check' => true,
'health_check_interval' => 30,
这会让连接池每 30 秒对每个空闲连接发起一次 PING 探测；若失败，则立即销毁该连接并触发重建。
不启用 health_check 时，网络闪断或 Redis 临时不可用后，连接池可能长期持有已失效的 socket，后续请求直接报错 Connection refused 或卡死。
缓存策略分级落地
第一步：识别高频读、低频写、强一致性要求三类数据。
第二步：对高频读数据（如商品基础信息），使用 Cache::remember('goods:1001', 3600, fn() => $service->getGoods(1001))，设置 TTL 为 3600 秒，避免穿透数据库。
第三步：对低频写数据（如用户个人资料），改用 Cache::rememberForever('user:123:profile', fn() => $service->getUserProfile(123))，配合主动失效（Cache::delete('user:123:profile')）而非被动过期，降低缓存 miss 比率。
第四步：对强一致性场景（如库存扣减），跳过缓存直连 Redis 原生命令（$redis->decr('stock:1001')），并用 Lua 脚本包裹原子操作，防止缓存与 DB 不一致。
禁用默认缓存键前缀与序列化方式
方法一：关闭自动前缀
在 config/autoload/cache.php 中，将 'prefix' => 'hyperf:' 改为空字符串 ''，避免不同服务共用同一 Redis 实例时键名冲突。
方法二：切换序列化引擎
将 'serializer' => Hyperf\Cache\Serializer\PhpSerializer::class 替换为 Hyperf\Cache\Serializer\IgBinarySerializer::class：igbinary 序列化体积更小、速度更快，尤其适合含大量数组或对象的缓存值。
注意：切换 serializer 后，旧缓存键无法被反序列化，需在灰度发布时先清空对应 namespace 缓存，否则读取返回 null。
