Django不解决缓存穿透，需在业务层用布隆过滤器前置拦截；cache.get()无法判断key是否存在，空值缓存仅缓解不治本；布隆需预热、全局单例、配合exists校验，误判率与内存需权衡。
Django 本身不解决缓存穿透，它只提供缓存抽象层；穿透问题必须在业务逻辑层前置拦截——布隆过滤器不是 Django 内置组件，得自己集成，且关键在于「预热时机」和「更新一致性」。
为什么 Django 的 cache.get() 挡不住缓存穿透
因为 cache.get() 只查缓存，不判断“这个 key 是否可能真实存在”。当请求一个数据库里压根不存在的 user_id=999999999 时，cache.get() 返回 None，接着你必然调用 User.objects.filter(id=...)，而 DB 查询结果也是空，缓存不会被写入，下一次同 ID 请求重复走完整条链路。
这和 Django 缓存配置无关，无论你用 Redis、Memcached 还是本地内存，只要没在查缓存前加一层“存在性快速筛检”，就拦不住穿透。
- 缓存空值（
cache.set(key, None, 60)）能缓解但不治本：攻击者用海量随机 ID，Redis 会迅速堆积无效 key -
get_or_404()或exists()查询仍打 DB，只是提前失败，没减少 IO - Django 中间件或装饰器里做参数校验（如 ID > 0）只能挡明显非法值，挡不住格式合法但实际不存在的 ID
如何在 Django 项目中接入布隆过滤器
核心思路是：把所有「理论上可能存在的 ID 集合」（比如全量用户 ID、已上架商品 ID）一次性加载进布隆过滤器，查询前先过它。不能依赖运行时动态构建，否则起不到拦截作用。
立即学习“Python免费学习笔记（深入）”；
仅使用 Python 将 Claw Code 虚拟化框架与 OpenClaw 集成，提供 184 种工具和 200 多条命令，用于安全分析和代码质量...
推荐用 pybloom_live（支持扩容）或 bloom-filter（轻量），避免手写位数组出错：
from pybloom_live import ScalableBloomFilter
<h1>初始化：预计总量 1000 万，误判率 0.1%</h1><p>bloom = ScalableBloomFilter(
initial_capacity=10_000_000,
error_rate=0.001,
mode=ScalableBloomFilter.SMALL_SET_GROWTH
)</p><h1>预热：启动时从 DB 或离线文件加载全部有效 ID</h1><p>for user_id in User.objects.values_list('id', flat=True).iterator():
bloom.add(user_id)</p>- 不要在每次请求里重建
ScalableBloomFilter实例，必须全局单例或通过 Django cache 存储序列化后的位数组 - 预热不能放在
models.py或apps.py的模块级代码里，容易导致迁移命令失败；建议写成 management command，在部署后手动触发 - 如果业务有频繁增删（如商品上下架），需额外维护一个异步任务监听变更，调用
bloom.add()或重建过滤器——布隆过滤器本身不支持删除
might_contain() 返回 True 时为什么还要查数据库
因为布隆过滤器只保证「False → 一定不存在」，但 True 表示「可能存在」，存在误判。比如某个刚被删除的用户 ID，布隆里还标记为存在，你跳过 DB 查询直接返回 404 就错了。
所以正确流程是：
def get_user_view(request, user_id):
if not bloom.might_contain(user_id): # ✅ 必定不存在，立刻返回
return JsonResponse({'error': 'not found'}, status=404)
<pre class='brush:python;toolbar:false;'># ❗️这里仍要走完整缓存+DB 流程
cache_key = f"user:{user_id}"
cached = cache.get(cache_key)
if cached is not None:
return JsonResponse(cached)
try:
user = User.objects.get(id=user_id) # 真实存在才查
cache.set(cache_key, model_to_dict(user), 3600)
return JsonResponse(model_to_dict(user))
except User.DoesNotExist:
cache.set(cache_key, None, 60) # 空值兜底，防短时误判
return JsonResponse({'error': 'not found'}, status=404)- 误判率设太高（如 5%），
might_contain()返回True太多，布隆就失去意义；设太低（如 0.0001%），位数组暴涨，初始化慢、内存占用高 - 永远不要把
might_contain()当作最终判定依据，它只是第一道闸门 - 空值缓存 TTL 必须比布隆预热周期短，否则新插入的数据在布隆里还没同步，空值又没过期，就会出现“数据已存在但接口返回 404”的现象
真正难的不是代码怎么写，而是决定哪些 key 集合值得放进布隆过滤器、预热数据源是否可靠、以及当 DB 和布隆状态不一致时，业务能否容忍那几秒的延迟或误判。这些没法靠库自动解决，得盯着监控看误判率曲线和 DB 查询 QPS 下降幅度来调。
