布隆过滤器容量n是硬上限，超量插入会导致误判率飙升至接近100%；必须按生命周期最大唯一项预估n并预留30%余量，Test()返回true后须二次校验，Add()并发需加锁，key需严格清洗。
为什么用 bloom.New() 初始化后插入超量就误判飙升
布隆过滤器不是“能装多少就装多少”的弹性容器，bloom.New(n, p) 中的 n 是硬上限：它决定了位数组长度 m 和哈希函数个数 k，一旦实际插入元素数超过 n，位数组被置 1 的比例快速趋近 100%，Test() 返回 true 的概率就不再是预设的 p，而是接近 1。这不是 bug，是数学必然。
-
n必须按「你整个生命周期里最多可能插入多少个唯一项」来设，不是当前已有数量，也不是日均增量 - 留 20% 余量是工程惯例：比如预估 800 万 URL，用
bloom.New(10_000_000, 0.001) - 别指望靠“先跑着，满了再重建”——重建需全量重放，期间无法服务；高频写场景建议预估时直接上浮 30%
Test() 返回 true 后必须二次校验，否则就是生产事故
filter.Test(key) 返回 true 只代表“这个 key 很可能已存在”，不是“它一定存在”。跳过后续确认直接丢弃或拒绝，就会把误判当成真实重复，造成数据丢失（比如爬虫漏抓、风控放过恶意请求）。
- 典型安全链路：
Test() == false→ 直接放行；Test() == true→ 查Redis SET或本地map[string]struct{}确认是否真重复 - 二次存储推荐用
SETNX+ TTL，避免并发写入冲突；若用本地 map，注意加锁或用sync.Map - 千万别在
Test() == true时顺手调Add()——布隆过滤器不负责去重，只负责快速拦截；重复Add不影响结果，但浪费 CPU
并发 Add() 必须加锁，Test() 可无锁但不能省略校验
github.com/yourbasic/bloom 的 Add() 不是并发安全的。底层是 []byte，而 bitArray[i/8] |= mask 是“读-改-写”三步操作，两个 goroutine 同时算出同一字节位置会竞态覆盖，导致位未置 1，最终引发漏判（false negative）——这违反布隆过滤器“零漏判”承诺。
Alibabacloud Sdk Client Initialization For Golang
下载
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 最简方案：
sync.RWMutex，Add()用Lock()，Test()用RUnlock() - 高频写场景可考虑
bbloom.WithPool()复用哈希计算状态，减少 GC 压力 -
Test()本身是只读，可无锁，但绝不意味着“返回 true 就可信”——它的并发安全性与业务逻辑兜底无关
文件去重时 key 提取错一个字符，整个 filter 就失效
布隆过滤器对输入极其敏感："user_123" 和 "user_123\n"、"\ufeffuser_123" 在位数组中映射到完全不同的位置。直接拿 scanner.Text() 结果 Add()，等于把噪音当 key，位数组迅速饱和，误判率几天内就崩到 50% 以上。
立即学习“go语言免费学习笔记（深入）”；
- 每行必须做
strings.TrimSpace()，且检查是否为空；BOM 头用bytes.TrimPrefix(line, []byte("\ufeff"))清理 - 从日志中提 key 要精准：用正则
order_id=([a-zA-Z0-9_]+)，而不是整行或模糊子串匹配 - 别用
fmt.Sprintf("%s:%s", a, b)拼接 key——字段顺序、分隔符稍有不一致，hash 结果就完全不同
