Hyperf中设置Redis缓存过期时间应优先用setex或显式传正整数$ttl，避免传null/0导致永不过期；Cacheable的getCacheTTL仅对主键查询生效，且需启用ModelCache组件；并发刷新access_token需结合提前刷新策略与Redis分布式锁。
Hyperf里设置Redis缓存过期时间用set还是setex
直接用setex更稳妥。Hyperf的Hyperf\Cache\Driver\RedisDriver在调用set时若传入$ttl参数，底层会自动转成setex或psetex（毫秒级），但前提是$ttl为整数且 > 0；如果传null或负数，它会 fallback 到普通set，导致永不过期。
常见错误现象：缓存没按预期失效，查 Redis 发现 key 确实没 TTL —— 很可能是因为业务代码里写了$cache->set($key, $value, null)，或$ttl被意外计算为0。
- 显式指定整数秒：
$cache->set('user:1001', $data, 3600) - 避免动态计算出
0：$ttl = max(60, $this->getDynamicTTL()); - 毫秒级需用
psetex语义：传1000表示 1 秒，不是 1 毫秒；真要毫秒请用Hyperf\Redis\Redis::psetex()直连
为什么Cacheable Trait 的getCacheTTL()有时不生效
因为Cacheable只对模型查询方法（如find()、first()）生效，且必须配合Hyperf\ModelCache组件启用。如果走的是where()->get()或原生 SQL 查询，这个方法完全不会被调用。
使用场景受限明显：它生成的缓存键格式是mc:%s:m:%s:%s:%s，依赖主键或唯一索引字段；一旦查询条件含非主键字段（比如where('status', 1)），就无法命中缓存，自然也谈不上 TTL 控制。
- 确认是否启用了
Hyperf\ModelCache：检查composer show | grep model-cache - 只对单条主键查询有效：
User::find(1001)✅，User::where('email', 'x@y.z')->first()❌（除非 email 是主键） - 自定义 TTL 必须返回
int，不能返回string或float，否则静默降级为默认值
并发刷新导致重复请求企业微信 API 怎么破
这不是 Redis 过期机制的问题，而是多个 Hyperf 实例同时发现 token 过期、各自去调企业微信拿新 token 导致的。单纯靠expire命令解决不了——Redis 的过期是被动触发，不提供“即将过期”通知。
正确做法是预留缓冲期 + 分布式锁。例如 token 官方有效期 2 小时，你设 Redis TTL 为 7000 秒（约 1h56min），并在每次获取前检查剩余时间是否 Hyperf\Redis\Redis::setnx()争锁，成功者刷新，失败者等待并重试。
- 不要等 Redis key 真过期才刷新，那已经晚了
- 锁 key 命名建议带业务标识：
lock:wechat:access_token，避免和其他锁冲突 - 锁必须设 TTL（如 10 秒），防止死锁；刷新完成后主动
del该锁 key - 等待逻辑别用
sleep()，改用co::usleep(100000)协程让出控制权
Redis 过期事件（Keyspace Notification）在 Hyperf 里能用来做自动续期吗
不能直接用于缓存续期。Redis 的__keyevent@0__:expired消息只是个事后通知，收到时 key 已经没了，无法读取原值来触发刷新。它适合做日志记录、异步清理、或触发下游补偿（比如发告警），但不适合“自动续期”这种需要读-改-写原子操作的场景。
真正需要的是“预过期检查”：在业务读缓存前，先用pttl查剩余毫秒数，若低于阈值则同步/异步刷新。这比依赖过期事件可靠得多，也更容易控制并发。
- 启用过期事件要改 Redis 配置：
notify-keyspace-events Ex，生产环境常被禁用，不可依赖 -
pttl命令返回-2（key 不存在）或-1（无过期时间），需区分处理 - 高频调用
pttl本身有开销，建议只对关键缓存（如 access_token）做，非核心数据用固定 TTL 更轻量
最易被忽略的一点：缓存续期逻辑如果放在协程里，但没做超时控制，一次卡住可能拖垮整个协程调度。务必给 HTTP 请求加timeout，锁操作加expire，所有外部依赖都设兜底 fallback 值。
