zcount统计区间为闭区间且要求分数为合法浮点数，负无穷用-inf、正无穷用+inf；字符串分数会导致插入失败或统计异常；集群下仅支持单key，多维筛选需结合其他结构。
ZCOUNT 能直接统计，但区间边界和数据类型稍不注意就会漏数或报错
ZCOUNT 的区间是闭区间，min 和 max 都包含在内
很多人以为 ZCOUNT 像 SQL 的 BETWEEN 一样默认左闭右开，其实不是——它默认就是左右都闭。比如想查分数在 80 到 90（含）之间的人数，直接写 ZCOUNT myzset 80 90 就行。
- 如果要用开区间，得加括号前缀：
ZCOUNT myzset (80 (90表示 >80 且 >90，注意两个括号都要加 - 负无穷用
-inf，正无穷用+inf，不能写成null或空字符串，否则报错ERR min or max is not a float - 分数必须是合法浮点数格式，
"80.0"可以，"80分"或"80-90"会直接导致命令失败
分数为字符串时 ZCOUNT 失效，必须确保 score 是数值类型
ZSet 的 score 字段在底层强制为 double 类型，但如果你用 ZADD 时传了字符串（比如 ZADD myzset "95" "user1"），Redis 会尝试转换；一旦转换失败（如 "95a"），该 member 就不会被插入，而你可能根本没意识到数据没进去。
- 插入前用
is_numeric()（PHP）或float.TryParse()（C#）等做校验，别依赖 Redis 自动转 - 已有脏数据？用
ZRANGE myzset 0 -1 WITHSCORES检查 score 是否全为数字，非数字的会显示为"nan"或触发错误 - Java 中用
Jedis.zadd()传Double而非String，避免隐式 toString() 导致写入字符串字面量
大数据量下 ZCOUNT 性能不错，但别拿它当实时排行榜聚合用
ZCOUNT 时间复杂度是 O(log(N)+M)，其中 N 是 zset 总长度，M 是命中区间内元素个数。它不遍历全量，而是走跳表的区间查找路径，所以哪怕 zset 有百万成员，只要区间窄（比如查 95–96 分之间），响应也很快。
- 但如果频繁查宽区间（如
ZCOUNT myzset 0 +inf），M 接近 N，实际就退化成 O(N) —— 这时不如缓存总数字段，用INCRBY维护 - 注意：Redis Cluster 下
ZCOUNT只支持单 key，跨 slot 的 zset 不支持，否则报错CROSSSLOT Keys in request don't hash to the same slot - 如果业务需要多维筛选（比如“80–90 分且城市=北京”），ZCOUNT 无能为力，得配合其他结构（如 Hash + SCAN 或 ES）
边界符号、数据类型、集群限制这三点，线上出问题八成栽在这儿，尤其是把用户输入的分数字符串直接拼进 ZCOUNT 命令里——看着像执行成功，其实返回 0，还找不到原因。
