go无内置hyperloglog，必须用第三方库：axiomhq/hyperloglog（轻量、redis兼容）或segmentio/ksuid/v2/hyperloglog（hll+、小基数更准但api复杂）；自实现易致误差飙升，precision参数实为寄存器数量控制（2^precision），混用库或哈希不一致会导致合并结果错乱。
Go里没有内置的HyperLogLog，别白找golang.org/x/exp/maps
Go标准库和x/exp包里压根没有HyperLogLog实现。golang.org/x/exp/maps只提供泛型map操作，跟概率性基数估算完全无关。你搜hyperloglog却翻到这个包，说明已经踩进误区了——它连哈希分布、寄存器、稀疏编码这些概念都不处理。
必须用第三方库：github.com/axiomhq/hyperloglog（轻量、兼容Redis默认精度）或github.com/segmentio/ksuid/v2/hyperloglog（HLL+，小基数更准、内存省，但API稍绕）。自己手写？register分配、bias校正、sparse/dense切换全得重推，实测误差容易从0.8%飙到15%以上。
Add()该传什么：字符串、结构体、int64都行，但别传哈希值或指针
两个主流库的Add()接收interface{}，内部用hash/fnv或hash/maphash做一致性哈希。传"user:123"、struct{ID int}{123}、甚至int64(123)都安全——前者有编码开销，后者更快且无歧义。
- 绝对不要传
sha256.Sum256这类哈希结果：HLL依赖哈希输出的均匀分布，你提前哈希就破坏了这个前提 - 避免传
&v：地址每次不同，会被当成不同元素；传[]byte安全，但传*[]byte就危险——哈希的是指针地址
New()的precision参数不是“小数位数”，而是寄存器数量控制开关
hyperloglog.New(precision)的precision取值范围是4–16，它决定寄存器个数m = 2^precision。这不是精度调节旋钮，而是直接挂钩误差和内存：
- precision=14 → m=16384寄存器 → Redis默认配置，误差≈0.81%，内存≈12KB
- precision=10 → m=1024寄存器 → UV统计够用，内存不到1KB，误差约±2%
- 设成16会panic；低于4则寄存器太少，算法失效
- 别盲目拉高：precision每+1，内存翻倍，误差仅略降——UV场景用10–12，广告曝光去重才需13–14
合并多个HLL时，Merge()签名不统一，混用直接panic
这是最容易翻车的点：axiomhq/hyperloglog的Merge是方法调用hll1.Merge(hll2)，而segmentio/ksuid/v2/hyperloglog是函数式hllplus.Merge(dst, src)。两者返回值、参数顺序、是否修改原对象全都不一样。
如果你项目里同时引入两个库，或者从Redis读HLL再用Go合并，务必确认精度和哈希函数一致（Redis用murmur3，Go库默认fnv，需显式配置），否则merge后结果完全不可信——不是不准，是彻底错乱。
实际部署时，选一个库贯穿始终，别在不同模块里混用；和Redis互通时，precision必须对齐，哈希函数也得手动配成一致，否则PFCOUNT和Go算出来的数永远对不上。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
