布隆过滤器必须在controller入口处立即调用，即请求→提取key→bloom.mightcontain(key)→false则直接返回，绝不能置于redis或db查询之后；需全量预热合法key、与缓存key完全一致、进程内单例部署，并配合空值缓存与参数校验分层防御。
布隆过滤器必须在Controller入口就调用，不能等Redis查询失败后补救
缓存穿透的防御失效，90%是因为布隆过滤器放错了位置。常见错误是：先执行 IDatabase.StringGetAsync("user:123456789")，没命中再查DB，最后才去判断 bloom.Contains("user:123456789")——此时请求早已穿透到数据库，布隆过滤器完全失去意义。
正确顺序只能是：接收请求 → 提取 key（如 "user:" + userId）→ 立即调用 _bloomFilter.MightContain(key) → 返回 false 就直接 return NotFound()，不进任何缓存或DB逻辑。
- 拦截点必须在 Action 方法最开头，且在任何
await _cache.GetStringAsync(...)或await _db.Users.FindAsync(...)之前 - key 构造要和后续缓存 key 完全一致，否则布隆“认为存在”但缓存查不到，仍会穿透
- 不要复用同一个
BloomFilter实例处理不同业务域（如 user 和 order），应按前缀隔离，避免误判率叠加
初始化必须全量加载合法 key，不能只塞热点或靠运行时增量
布隆过滤器不是机器学习模型，不会自动“学会”哪些 key 合法。如果只在用户注册时调用 BF.ADD，那存量 5000 万用户根本不在过滤器里，攻击者随便扫个 user:1 就能穿透。
启动时必须从权威源（如 MySQL 的 SELECT id FROM users）一次性加载全部有效 ID，并构建完整 key（如 "user:1", "user:2"）批量注入。.NET 中推荐用 Microsoft.Extensions.Caching.BloomFilter 的 InitializeAsync(IEnumerable<string> keys)</string>。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 加载过程需异步非阻塞，避免拖慢应用启动；可用后台服务分批拉取+合并
- 增量更新仅用于新增数据（如新用户注册成功后同步
_bloomFilter.Add("user:123456789")），不能替代全量初始化 - 软删除用户后，该 key 仍留在布隆中（因不支持删除），此时必须配合空值缓存兜底，写入
"NULL_VALUE"并设 TTL ≤ 300 秒
空值缓存必须用字符串字面量，禁用泛型序列化
很多人用 _cache.SetAsync("user:999999999", null, options) 或序列化一个 null 对象，结果是 Redis 里存了 "null" 或空 JSON，后续反序列化时报错，或无法与真实业务空值区分。
空值缓存的唯一目的是标记“这个 key 查无此物”，必须用确定、可识别的字符串标记，比如 "@NULL@"，并显式检查：
var cached = await _cache.GetStringAsync(key); if (cached == "@NULL@") return NotFound();
- 写入必须用
GetStringAsync/SetStringAsync，绕过ISystemTextJsonSerializer等泛型序列化器 - TTL 建议设为
TimeSpan.FromMinutes(2)～TimeSpan.FromMinutes(5)，太长会挤占内存，太短起不到缓冲作用 - 空值只对通过布隆过滤器的 key 写入；非法 key（如
user:-1）应在 Controller 层用[Range(1, int.MaxValue)]直接拦截，不进布隆逻辑
集群环境下布隆过滤器必须进程内单例，不能依赖RedisBloom模块
Redis 集群本身不支持全局布隆过滤器——BF.RESERVE 命令在某个分片上创建的 filter，对其他分片不可见；而客户端发来的 user:123 可能路由到任意节点，导致漏判。
所以 .NET 应用必须自己维护进程内布隆过滤器实例（如 static BloomFilter _instance 或 DI 单例），并在 Program.cs 中注册为 AddSingleton<ibloomfilter bloomfilter>()</ibloomfilter>。RedisBloom 模块只适合单机场景，集群中启用它反而增加误判风险。
- 初始化参数不能拍脑袋：若预计 3000 万用户、允许误判率 0.01%，位数组大小约需 120MB，需提前计算并预留内存
- 必须有后台定时任务（如
HostedService）每 6 小时全量重建一次，防止因长期增量写入导致误判率漂移 - 别忘了对空值 key 也做登记：DB 查询返回 null 后，立即
_bloomFilter.Add(key)，否则下次同 key 请求仍会穿透
