直接用HyperLogLogOperations更稳妥，因其封装了命令调用与类型转换，避免手动序列化导致ClassCastException或PFCOUNT返回0；须用StringRedisTemplate配置并显式声明Bean，禁用默认JDK序列化器。
为什么直接用 HyperLogLogOperations 比自己拼 key + redisTemplate.opsForHyperLogLog() 更稳妥？
Spring Data Redis 提供了 HyperLogLogOperations，它封装了底层命令的调用逻辑和类型转换，避免手动处理序列化/反序列化导致的 ClassCastException 或空值误判。如果你直接用 redisTemplate.opsForHyperLogLog()，默认序列化器（如 JdkSerializationRedisSerializer）会把字符串转成字节数组再套一层对象包装，PFADD 实际存的是乱码，后续 PFCOUNT 就会返回 0。
实操建议：
- 在配置类中显式声明
HyperLogLogOperationsBean，绑定到 String 类型的 key 和 value（即使用StringRedisTemplate的 ops） - 不要复用通用
RedisTemplate的opsForHyperLogLog()，除非你已重置其序列化器为StringRedisSerializer - key 命名建议带业务前缀和日期，比如
uv:login:20240520，方便按天聚合或清理
PFADD 调用失败但没报错？检查这三点
HyperLogLog 的 PFADD 命令本身是幂等且几乎不报错的（除非 key 关联了非 HyperLogLog 类型），但 Spring 封装后可能因序列化、连接中断或 pipeline 批量提交失败而静默丢弃。常见现象是：代码执行无异常，但 PFCOUNT 始终为 0。
排查要点：
- 确认是否用了
StringRedisTemplate获取HyperLogLogOperations，而不是泛型RedisTemplate - 检查 Redis 服务是否启用了 AOF 或 RDB 持久化——某些低配环境（如 Docker 默认配置）可能禁用持久化，重启后数据丢失，误以为写入失败
- 如果批量调用（如用户登录时记录），避免在循环里反复调用
add()；改用add(key, values...)单次提交，减少网络往返
如何按日统计 UV 并支持跨天去重？
单日 UV 直接用一个 key 即可，比如 uv:page:home:20240520；但要做「近 7 天独立访客」，不能简单相加（有重叠），得用 PFMERGE 合并多个 HyperLogLog，再 PFCOUNT。Spring Data Redis 通过 union() 方法暴露该能力。
注意点：
-
union()是原地合并：目标 key 会被覆盖，源 keys 不变；若想保留原始日粒度数据，先copy()再 merge - 合并操作是 O(N) 时间复杂度（N 为 key 数量），不要在请求链路中实时做 30 天合并；建议凌晨用定时任务预计算并存为新 key，如
uv:7d:20240520 - 如果需要精确去重（比如审计场景），HyperLogLog 不适用——它只有 0.81% 标准误差，此时应换 Bitmap 或布隆过滤器 + MySQL 回溯
为什么本地开发用 Lettuce 连 Redis 会偶尔 PFCOUNT 返回 -1？
这是 Lettuce 客户端在连接未就绪或 channel 关闭时的 fallback 行为，不是 Redis 返回的。典型触发场景：应用刚启动、Redis 临时断连、或测试时频繁启停。
解决方式：
- 检查
LettuceClientConfigurationBuilderCustomizer是否设置了合理的超时和重连策略，例如timeout(2, TimeUnit.SECONDS)和pingBeforeActivateConnection(true) - 在调用
size()（对应PFCOUNT）前，加一层redisTemplate.hasKey(key)判断 key 是否存在，避免对不存在的 key 执行 count - 单元测试中不要依赖真实 Redis，用
EmbeddedRedis或 MockBean 模拟HyperLogLogOperations行为更稳定
UV 统计真正难的不是写那几行 add() 和 size()，而是 key 的生命周期管理、误差边界的认知、以及高并发下客户端连接池和序列化器的隐性耦合——这些地方一松懈，数据就悄悄不准了。
