Go官方未提供HyperLogLog实现，golang.org/x/exp/maps仅处理普通map操作，与概率性基数估算无关；必须使用第三方库如github.com/axiomhq/hyperloglog或github.com/segmentio/ksuid/v2/hyperloglog。
为什么直接用 golang.org/x/exp/maps 不行
HyperLogLog 是概率性基数估计算法，不是标准库或 x/exp 包里的功能。Go 官方至今没提供任何 HLL 实现，maps 包只处理普通 map 操作，跟流式去重计数完全无关。想用 HLL，必须引入第三方库或自己实现——而自己从头写易出错（比如 bias 校正、sparse mode 切换、register 分配），不推荐。
选 hyperloglog 还是 hyperloglogplus
主流两个 Go 库：github.com/axiomhq/hyperloglog（简称 hll）和 github.com/segmentio/ksuid/v2/hyperloglog（实为 HyperLogLog++ 实现）。前者简单轻量，支持 32-bit register；后者兼容 Google 的 HLL+ 规范，对小基数更准、内存更省（sparse encoding），但 API 略复杂。
- 如果你只要快速估算 UV、日志去重等通用场景，
hyperloglog足够，初始化快、方法少、不易误用 - 如果数据分布极不均匀（比如 90% 的 key 只出现 1–2 次），或需要和 BigQuery / Redis 的
PFCOUNT结果对齐，优先选hyperloglogplus - 注意：两个库的
Merge方法签名不同——hll是(*HLL).Merge(other *HLL)，而hllplus是hllplus.Merge(dst, src)，混用会 panic
Add 传字符串还是哈希值？为什么不能直接传 []byte
Add 接收的是任意 interface{}，内部会用 hash/fnv 或 hash/maphash 做一致性哈希。你传 "user:123" 或 struct{ID int}{123} 都可以，但别手动传哈希值（比如 sha256.Sum256 的结果），否则会破坏 HLL 对 hash 分布的假设，导致误差飙升（实测相对误差从 0.8% 涨到 >15%）。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 避免传指针：
&v每次地址不同，会被当成不同元素 - 传
[]byte是安全的，因为库会按字节内容哈希；但传*[]byte就危险——它哈希的是指针地址 - 如果原始数据是整数 ID，直接传
int64比转成 string 再哈希更快，且无编码歧义
内存与精度怎么平衡？New() 的参数到底控制什么
hyperloglog.New() 的唯一参数是 precision（取值 4–16），它决定 register 数量：m = 1 。这不是“保留几位小数”，而是直接影响误差和内存：
-
precision=10→ ~1024 个 register → 内存约 1KB，标准误差 ≈ 1.04 / √1024 ≈ 3.2% -
precision=14→ ~16K register → 内存约 16KB，误差 ≈ 0.8% - 超过 16 会 panic；低于 4 则 register 不足，算法失效
- Redis 的默认 precision 是 14；如果你要和 Redis 的
PFADD互通，必须用相同 precision + 相同哈希函数（需额外配置）
实际中，UV 统计用 10–12 足够；实时广告曝光去重建议 13–14；别盲目设高——内存翻倍，精度只提升一点点。
真正容易被忽略的是：HLL 不支持删除操作，也没法精确查某个元素是否在集合里。它只回答“大概有多少个不同元素”。如果业务需要“排除某类 ID 后再统计”，得换用 roaringbitmap 或分桶 + 定期重建。
