布隆过滤器在语言学习服务中必须与业务key生命周期强绑定，严格遵循Test→cache.Get→DB查询顺序，key格式需统一且预热一致，n/p参数应按数据规模分设，Add操作须与DB写入同步，定期全量重建以防误判率上升。
布隆过滤器在缓存优化中不是“配个参数就能用”的组件，它必须和业务 key 的生命周期、格式、写入路径强绑定——尤其在语言学习类服务（如词库查询、用户学习记录校验）中，key 往往带 locale、version、user_id 等多维前缀，稍不注意就全量失效。
filter.Test() 必须在 cache.Get() 之前调用
这是硬性调用顺序，跳过等于放弃布隆过滤器的价值。语言学习场景下常见错误是：先查 Redis，miss 后再调 filter.Test()，结果恶意构造的 word:en:999999999 或 phrase:ja:invalid 已经打穿缓存直击 DB。
- 正确链路：
if !filter.Test([]byte(key)) { return nil, false }→ 再走cache.Get(key)→ miss 后才进singleflight.Do()查 DB - Test 返回
false时，必须立即返回，不查缓存、不查 DB、不打日志（避免被扫描利用） - Test 返回
true仅表示“可能存在”，仍要走完整缓存+DB 流程，否则误判会直接污染业务逻辑
key 格式必须与预热时完全一致
语言学习服务的 key 常含动态片段，比如 dict:zh:verb:吃、progress:uid123:lesson:v2。布隆过滤器对字节敏感，任何编码/大小写/空格/前缀差异都会导致 Test() 永远返回 false。
- 预热时从 DB 或 dump 文件加载的 key，必须用和线上查询**完全相同的序列化方式**：统一 UTF-8、不加额外 JSON 包裹、不自动 trim 空格
- 推荐做法：定义一个
canonicalKey()函数，所有入口（API、定时任务、后台写入）都走它生成 key，预热也用它 - 特别注意 emoji 或生僻字：Go 默认 string 是 UTF-8，但若前端传的是 GBK 编码再转 string，
[]byte就会错位
n 和 p 参数要按语言数据规模设，不能复用通用模板
词典类数据增长慢但总量大（如《现代汉语词典》约 7 万词，加例句/变体可能超 500 万），而用户学习进度 key 增长快但单用户稀疏。混用同一组 n、p 会导致小集合内存浪费、大集合误判飙升。
立即学习“go语言免费学习笔记（深入）”；
- 词库类（静态、全量可预知）：
bloom.New(10_000_000, 0.01)—— 支撑千万级词条，误判率 1%，内存约 12MB - 用户进度类（动态、ID 散列）：
bloom.New(50_000_000, 0.001)—— 预估三年用户达 5000 万，每用户平均 10 条进度，误判率压到 0.1%，内存约 100MB - 切忌用
bloom.New(1000, 0.01)测试完就上线，n 填小了后期无法扩容，只能重建 + 切流量
Add() 必须与 DB 写入强同步，且只增不删
语言学习服务常有“词删除”“课程下架”操作，但布隆过滤器不支持删除。强行 Add() 所有新词、却漏掉下架词的清理，会导致已下架内容长期被误判为“存在”，用户查不到却无提示。
- 写 DB 成功后，立刻
filter.Add([]byte(canonicalKey))，建议包在同一个事务或用消息队列保证最终一致 - 删数据时不要动 filter，靠
cache.Set(key, nil, time.Minute*5)设置空值缓存兜底 - 每月凌晨低峰期跑一次全量重建：dump 当前有效 key 列表 → 新建 filter → 原子替换指针 → 旧 filter GC
最容易被忽略的是 key 格式对齐和全量重建节奏——前者让过滤器形同虚设，后者让误判率随时间缓慢爬升，监控上只看到缓存 miss 率微升，根本查不到根源。
