simplecache::get()不能直接配合setnx防击穿，因其无原子性且存在竞态窗口；须用redis原生命令set nx px完成判断加锁一体、双检、lua删锁闭环。
缓存失效瞬间大量请求打 DB，不是锁没加，而是锁没加对、没加稳。 Hyperf 的 SimpleCache 接口本身不带锁能力，直接套用会导致「看似加了锁，实则全量穿透」——关键在锁的生命周期、重试逻辑和空值处理是否闭环。
为什么 SimpleCache::get() 不能直接配合 setnx 做击穿防护
SimpleCache 是 PSR-16 标准接口，只提供 get/set/delete 等基础方法，没有原子性锁操作。常见错误是：先 get 判空，再用 Redis::set 加锁 —— 这中间存在竞态窗口，多个协程可能同时判空、同时尝试加锁，导致锁失效。
- 必须用 Redis 原生命令（如
SET key value NX PX 5000）完成「判断 + 加锁」原子操作 -
SimpleCache::get()返回false不代表缓存一定不存在（可能存了null字符串），需额外约定空值标记（如"__NULL__"） - Hyperf 默认
SimpleCache实现（Hyperf\Cache\Driver\RedisDriver）底层用的是Redis::get，但加锁必须绕过它直连Redis实例
正确加锁流程：三步不可少
以获取用户为例，$key = "user:123"，核心是「查缓存 → 抢锁 → 查库回填」闭环，缺一不可：
- 第一步：用
$cache->get($key)尝试读，命中则直接返回；未命中且非空值标记，进入抢锁 - 第二步：用
$redis->set($lockKey, $token, ['NX','PX'=>5000])抢锁，$token必须唯一（推荐bin2hex(random_bytes(8))），避免误删他人锁 - 第三步：抢到锁后，再次
$cache->get($key)双检（防止锁期间别人已写入），再查 DB、$cache->set($key, $data, 300)，最后用 Lua 脚本安全删锁
删锁必须用 Lua：$lua = 'if redis.call("get", KEYS[1]) == ARGV[1] then return redis.call("del", KEYS[1]) else return 0 end'; $redis->eval($lua, [$lockKey, $token], 1);
轮询等待时最容易踩的三个坑
没抢到锁的协程不能直接返回 null，但也不能无脑重试。以下是高频翻车点：
- 用
sleep(0.05)而不是usleep(50000)：前者会主动让出协程，触发调度开销；后者更轻量，适合毫秒级等待 - 轮询超过 3 次仍为空，继续重试加锁 → 可能引发雪崩式重试，应直接降级（返回 null 或走本地缓存）
- 等待后只读一次缓存就结束 → 必须双检：读到非空才返回，读到空（或
"__NULL__"）就终止，不再重试加锁
Service 单例状态污染风险
Hyperf 默认 Service 是单例，如果在方法里用类属性临时存 $lockKey 或 $token，多个协程会互相覆盖。例如：
class UserService
{
private string $lockKey; // ❌ 危险！协程间共享
public function getUser(int $id)
{
$this->lockKey = "lock:user:{$id}"; // 多个请求同时写，值错乱
// ...
}
}
正确做法：所有锁相关变量都声明为局部变量，锁逻辑不依赖实例状态。空值标记也必须写死（如 "__NULL__"），不能动态拼接或从配置读取——否则不同协程可能生成不同标记，破坏空值拦截效果。
