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