加空值缓存是最简单有效的临时方案，需禁用序列化、用原子命令防并发写入，并避开Cache::remember()等易失效方法。
缓存穿透导致数据库被打崩，怎么快速止血
直接加空值缓存是最简单有效的临时方案。用户查一个根本不存在的 user_id=9999999，Redis 没命中就打 DB，DB 返回 null，你得把 cache_set('user:9999999', null, 60) 写进去——哪怕值是 null，也要设个 60 秒过期。否则攻击者轮着刷一堆非法 ID，缓存永远不生效。
注意：ThinkPHP 的 Cache::set() 默认序列化 null 会变成字符串 "b:0;"，取出来判断 === null 会失败。务必用 Cache::set($key, null, $ttl, ['serialize' => false]) 关掉序列化，或者统一用 Cache::set($key, '__NULL__', $ttl) 做标记值。
布隆过滤器不是万能的，别在 TP 里硬塞 RedisBloom
ThinkPHP 本身不带布隆过滤器支持，强行集成 redis-bloom 扩展或 Lua 脚本，会引入额外运维成本和兼容风险。更务实的做法是：只对「固定、可预知」的 ID 空间做前置过滤，比如用户表主键范围已知是 1~1000 万，那就用本地位图（$bloom = new \SplFixedArray(20000000)）+ 双 hash 函数做轻量级过滤；如果是商品 ID 这类不可预估的，优先走空值缓存 + 请求限流。
常见错误：
立即学习“PHP免费学习笔记（深入）”；
- 用
md5($id) % size当 hash —— 分布不均，误判率飙升 - 把布隆过滤器放在
Cache::get()之前，但没处理并发写入时的竞态，导致漏写 - 误以为布隆返回 false 就一定不存在，其实它只保证“true 时一定存在”，false 仍要查缓存和 DB
ThinkPHP 的 cache 配置容易让空值缓存失效
TP 默认缓存驱动（如 File 或 Redis）对 null 值的处理不一致：File 驱动会跳过写入，Redis 驱动默认序列化后存成字符串。必须显式配置驱动参数：
在 config/cache.php 中确认：'redis' => ['host' => '127.0.0.1', 'port' => 6379, 'serialize' => false]
否则 Cache::set('x', null) 实际存的是 "N;"，再用 Cache::get('x') === null 判断永远为 false。
另一个坑：TP 的 Cache::remember() 方法内部会先 get 再判断是否为空，如果缓存里存的是 "__NULL__" 字符串，它不会触发回调，直接返回字符串——所以空值缓存必须绕开 remember()，手写三段式逻辑。
高并发下空值缓存击穿，得加一层原子写锁
两个请求同时发现 user:123 缓存 miss，都去查 DB，都拿到 null，又都去 set 缓存——看似无害，但若 DB 查询本身有代价（比如连了慢查询），并发放大后依然压垮 DB。
解决方案不是加分布式锁，而是用 Redis 的 SET key value EX 60 NX 原子操作：
if (false === Cache::store('redis')->handler()->set($key, '__NULL__', ['nx', 'ex' => 60])) {
// 说明别人已经写进去了，当前请求直接放弃 set
}
注意：Cache::store('redis')->handler() 返回的是原生 Redis 实例（Predis 或 phpredis），才能调用底层命令；用 Cache::set() 无法实现原子性。
这事没法靠框架自动兜底，每次写空值缓存都得自己多写两行判断。漏一次，就可能被扫出雪崩点。
