thinkphp中cache::set('key', null, 300)无效，因redis驱动对null值序列化跳过、写入静默失败；应改用'__null__'等占位符并严格比较===，配合布隆过滤器前置校验与空值缓存兜底。
ThinkPHP里Cache::set('key', null, 300)为什么没用
它根本没存进 Redis，或者存成了空字符串、false，甚至被某些版本当作永久缓存。ThinkPHP 的 Redis 驱动对 null 值不友好：序列化时跳过、写入时静默失败、读取时和未命中返回值混淆（都是 null 或 false）。验证方法很简单：redis-cli GET user_999999 返回 (nil)，说明压根没写进去。
必须改用可识别的占位符：
- 统一用字符串如
'__NULL__'或结构化标记如json_encode(['_empty' => true]) - TTL 必须显式设短，建议
300（5 分钟）起，再加 ±10–20% 随机抖动，比如rand(270, 330) - 所有读取点必须用严格比较：
if ($data === '__NULL__')，禁用==（会把0、''、false全判成空） -
Cache::remember()不处理空结果——它只在回调返回非空时才写缓存，等于主动放弃防护
布隆过滤器必须前置校验，不能查完缓存再补
顺序错了就等于没防。正确链路是：请求进来 → 先 BF.EXISTS → 返回 0 就直接 404 → 存在才查缓存 → 缓存未命中才查 DB。如果先查缓存、再想“要不要加布隆”，那恶意 ID 已经打到 DB 了。
ThinkPHP 本身不支持布隆过滤器，topthink/think-bloom 扩展已多年未更新、集群下失效，别碰。稳妥做法是直连 Redis 原生命令：
- 确认 Redis 已加载
redisbloom模块：redis-cli MODULE LIST能看到bf - 初始化一次：
$redis->rawCommand('BF.RESERVE', 'user_bf', 0.01, 100000)（误差率 1%，预估容量 10w） - 仅在 DB 写入成功后调用：
$redis->rawCommand('BF.ADD', 'user_bf', $id)，不能在缓存层写入时就加 - 查询前判断：
$exists = $redis->rawCommand('BF.EXISTS', 'user_bf', $id) === '1'，为false就终止流程
空值缓存和布隆过滤器为什么必须一起上
单靠空值缓存，扛不住随机构造的非法 ID（比如 user:18273645901），每个新 ID 都写一条 '__NULL__'，Redis KEY 数量爆炸、内存疯涨；单靠布隆过滤器，它无法自动感知新插入的数据（比如后台刚注册一个用户），会导致“真实存在却被拦截”。
二者是互补关系：
- 布隆过滤器负责“减负”：筛掉 99% 以上的非法请求，不让它们碰 Redis 和 DB
- 空值缓存负责“兜底”：对漏过的、或新增后尚未同步进布隆过滤器的 ID，提供短暂保护
- 布隆更新成本高（全量重建 or 批量增量），空值缓存清理成本低（
Cache::rm('user:123')单 key 删除） - 线上必须监控
BF.EXISTS的 false-negative 率（应接近 0）和空缓存命中率（长期 > 80%）
所有读取入口必须走同一套判断逻辑
漏掉一个接口、一个中间件、一个手动绕过 Cache::get() 的地方，整个防护就失效了。不是“写了空值缓存”就万事大吉，而是“每次读都得按规则判断”。模型层的 append + getXxxAttr、列表页批量查、手动 SQL 查询……这些路径都得统一收口。
典型错误包括：
- 在控制器里直接
Db::name('user')->where('id', $id)->find()，完全绕过缓存层 - 用
Cache::tag()清理缓存时误删了空值 key，导致穿透重新发生 - 写操作后忘记
Cache::rm('user:'.$id)，空值缓存阻塞新数据生效 - 空标记 key 和业务 key 混用（比如都用
user_123），覆盖真实数据
最稳的做法是在 Service 层封装统一查询方法，所有上层调用只走这个出口，判断、缓存、写空值、删锁、打日志都在里面闭环。复杂点不在技术选型，而在所有读路径是否真正收敛。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
