thinkphp用setnx加锁仍打崩数据库，因未设过期时间致死锁、del锁未放finally致锁不释放、递归重试无上限致雪崩，且文件缓存不支持跨进程互斥，cache::tag()非锁机制，永不过期有数据不一致风险，redis配置中timeout、persistent、select及key命名隔离缺一不可。
ThinkPHP里用setnx加锁重建缓存，为什么还是打崩数据库？
因为setnx只管“设不设得成”，不管“设完谁来删”——锁没释放、异常没兜底、重试没上限，三个漏洞一齐开，互斥就形同虚设。
- 必须搭配
expire设置锁过期时间（比如5秒），否则服务挂掉就永久死锁 - 业务查询数据库失败时，
del锁的操作必须放在finally或catch里，不能只写在成功路径里 - 递归重试（如
usleep(50); get_data_with_mutex($key)）要加计数限制，否则1000个请求可能叠成上万次无效轮询 - ThinkPHP的
Cache::get()和Cache::set()底层若走文件缓存，根本无法跨进程互斥——务必确认已切到redis驱动并配置persistent => true
Cache::tag()能替代互斥锁防击穿吗？
不能。标签（tag）是批量清理用的逻辑分组，不是锁机制。它既不阻塞并发，也不保证原子性，对击穿零防护。
-
Cache::tag('user')->set($key, $data)只是给缓存打标，不影响其他请求读取或写入 - 想靠
Cache::tag('user')->clear()清空一批缓存？那反而会主动触发多key同时失效，加剧击穿风险 - 真正需要的是“单key独占更新权”，只有
SET key value NX PX 5000这类原子命令才能提供
把热点数据设为永不过期，noeviction策略真安全吗？
不安全。Redis的noeviction只防止LRU淘汰，但挡不住内存溢出、主从同步延迟、手动FLUSHDB等现实风险。
- 永不过期 + 高频更新 = 缓存与数据库长期不一致，尤其当更新走“先删缓存再改库”路径时，中间窗口期所有请求都读脏数据
- 若用“先改库再删缓存”，删失败就会永远脏——必须配补偿任务或监听binlog
- 更稳妥的做法是：设一个超长过期时间（如24h），配合后台定时
refresh脚本异步续期，既保新鲜度又避集中过期
ThinkPHP配置里哪些redis参数直接影响互斥效果？
三个关键配置项漏调一个，锁就可能失效：
-
'timeout' => 5：连接超时太短（如1），网络抖动时setnx失败，所有请求直接穿透 -
'persistent' => true：不启用长连接，每次请求新建Redis连接，setnx原子性还在，但性能暴跌，锁等待时间被放大数倍 -
'select' => 0：如果多个模块用了不同db索引（如session用db1，缓存用db2），但锁key和缓存key不在同一db，del锁操作就找不到目标
最容易被忽略的是锁key和业务key的命名空间隔离——比如缓存key用user:123，锁key却写成lock_user_123，看着合理，但一旦有人误删lock_*前缀，整个锁体系就塌了。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
