不适合，HyperLogLog仅能估算基数，无法判断单个邮箱是否存在；需准确去重时应使用SET或布隆过滤器（BF.ADD）配合二次校验。
HyperLogLog 适合做邮件地址去重吗？
不适合直接用 HyperLogLog 做“去重”——它不存原始数据，只估算基数，无法判断某个邮箱是否已存在。你没法用 PFADD 后再查 "user@example.com" 在不在里头。它只回答“大概有多少个不同邮箱”，不是“这个邮箱加过没”。
常见错误现象：
- 误以为
PFADD返回1表示“新增成功”，其实返回1只表示“估算值可能变了”，哪怕重复加同一邮箱也可能返回1 - 想靠
PFCOUNT结果反推去重后列表，但根本拿不到具体邮箱
使用场景仅限于：快速统计独立邮箱数量（比如“今日注册去重 UV”），不要求精确到个位（误差率约 0.81%），且完全不关心具体是哪些邮箱。
真正需要去重时该用什么？
用 SET 或带过期的 SET，配合 SISMEMBER + SADD 判断并写入。这是唯一能准确回答“这个邮箱有没有见过”的方式。
-
SET内存开销比HyperLogLog高得多，但换来的是确定性 - 单个邮箱字符串平均占 20–50 字节，百万级约需 50–100 MB 内存（取决于长度和 Redis 版本）
- 必须设
EX或用SETEX，否则长期累积会撑爆内存 - 不要用
HSET存邮箱（key 太碎）、也不要用LIST（查LRANGE+LREM是 O(n)）
示例逻辑：
EXISTS email:seen:user@example.com → 若不存在，执行 SET email:seen:user@example.com 1 EX 86400 → 同时用 SADD seen_emails:user_domain user@example.com（可选分桶）
为什么有人硬套 HyperLogLog？
因为混淆了两个需求：
- “今天来了多少新用户？” →
PFADD hll:signup:20240401 user@example.com✅ - “user@example.com 是不是第一次来？” → 必须用
SET或布隆过滤器（BF.ADD）❌
性能差异明显：
-
PFADD是 O(1)，常数时间，无论数据量多大 -
SISMEMBER平均 O(1)，但最坏 O(N)（哈希冲突严重时），实际百万级几乎无感 -
BF.ADD（RedisBloom）更快更省内存，但需额外模块，且有误判率（false positive），不能用于强校验场景
容易踩的坑：
- 把
PFADD当插入操作，后续没做任何业务层去重，导致重复发验证邮件 - 用
PFCOUNT做实时去重计数展示，结果发现每天数字在跳变（因估算抖动），被产品追问
如果真要省内存又需判断存在性，怎么办？
上 BF.ADD（布隆过滤器），但必须接受它偶尔说“见过”，其实没见过（false positive）。
- 安装 RedisBloom 模块后，用
BF.RESERVE emails 0.01 1000000创建一个误判率 1%、预估容量 100 万的过滤器 -
BF.ADD emails user@example.com返回1表示“可能新增”，0表示“肯定已存在” - 但
BF.EXISTS emails user@example.com返回1时，仍需查一次SET确认（二次检查）
关键限制：
- 不能删除元素（
BF.MADD可批量，但删不了） - 误判率越低，内存越大；容量预估偏小会导致误判率飙升
- 如果业务容忍“万分之一的用户收两次验证码”，那可以单用；否则必须搭配
SET回源
Redis 的内存模型很实在：你要确定性，就得为每个邮箱付字节；你要省字节，就得接受估算或概率判断。没有两全其美的命令。
