Redis HyperLogLog 是 ThinkPHP 项目中将单日 UV 内存从 GB 级降至 12KB 的唯一方案，误差 ±0.81%，支持 pfAdd/pfCount 操作，需按日期+业务域分片建 key、设过期、用稳定用户标识。
直接用 Redis HyperLogLog 替代 Set 存用户 ID，是 ThinkPHP 项目中唯一能将单日 UV 统计内存从 GB 级压到 12KB 的方案。它不存原始数据，只做概率估算，误差 ±0.81%，但对运营报表、大促看板完全够用。
ThinkPHP 8.0 中 pfAdd 和 pfCount 的调用方式
ThinkPHP 8.0 封装了 Redis 实例，无需手动 new Redis() 或引入扩展，直接走 cache + store 链路即可调用原生命令：
-
$this->cache->store('redis')->getRedis()->pfAdd('uv:20260817', $uid)：传入字符串型$uid（如'user_12345'或设备指纹哈希值），返回1表示该用户今日首次被识别，0表示已存在——别拿返回值判断“写入失败”，网络异常会抛异常，不是返回 0 -
$this->cache->store('redis')->getRedis()->pfCount('uv:20260817')：返回整型估算值，注意结果可能为null（key 不存在时），建议加空值判断或用?: 0 - 单次
pfAdd最多传 1024 个元素；超量不报错也不截断，低版本客户端可能静默丢弃，务必在业务层拆分
键名必须按日期+业务域隔离，不能复用
一个 HyperLogLog 固定占 12KB，但 key 复用会导致数据污染和无法下线：
- ✅ 推荐格式：
uv:page:home:20260817、uv:channel:wechat:20260817—— 按页面/渠道+日期分片，便于后续合并或单独查 - ❌ 禁止
uv:all、uv:total这类长期 key：数据永远累积，PFCOUNT 结果只会越来越大，且无法区分时间维度 - ❌ 禁止跨端混用：PC 端
user_id和 App 端device_id写进同一个 key，会导致同一自然人被当成多人或一人多次去重 - 每天首次写入后，顺手加过期：
expire('uv:20260817', 86400 * 30)，避免历史 key 永久堆积
用户标识必须稳定，严禁用 session_id 或随机 token
HyperLogLog 的去重能力完全依赖输入值的业务一致性：
立即学习“PHP免费学习笔记（深入）”；
- ✅ 优先用登录态下的
$user->id（字符串化，如(string)$user->id） - ✅ 未登录时 fallback 到设备指纹，例如：
sha1($_SERVER['HTTP_USER_AGENT'] . $_SERVER['REMOTE_ADDR'])，保证同一设备多次访问生成相同值 - ❌ 禁用
session_id()、uniqid()、前端生成的临时 token：每次刷新都变，把一人计成多人 - ❌ 空字符串
''、纯数字123虽然命令层面合法，但若业务上无法代表唯一自然人，就会导致漏统或误统
PFCOUNT 多 key 合并的真实开销与风险
调用 pfCount('uv:20260815', 'uv:20260816', 'uv:20260817') 看周 UV，表面是读操作，实则暗藏性能陷阱：
- 它等价于内存中临时
pfMerge再估算，并集去重——不是简单相加，所以结果必然 ≤ 各日 UV 之和 - 高并发下频繁多 key
pfCount会引发 Redis CPU 尖峰，因需实时合并 16384 个桶的哈希状态 - 线上建议：日常监控只查单日 key；报表类任务用定时任务离线合并，避开流量高峰；不要在用户请求链路里实时跑 7 个 key 的
pfCount - 如果某天数据异常（如 key 丢失），多 key 合并不会报错，但估算值会偏低，且无法定位哪天出问题
最易被忽略的一点：HyperLogLog 不支持回溯。你永远没法知道“今天新增的 UV 里有多少来自微信”，它只回答“总数是多少”。需要渠道维度拆解，必须从源头分 key，而不是指望后期从一个大 key 里捞出来。
