<p>直接用 redis-cli 直连验证最高效：ping 返回 PONG 表示连通；NOAUTH 需加 -a 密码；连接失败先查服务状态和端口映射；KEYS * 要防 shell 展开，改用 --scan；TYPE 查类型避免命令误用；HSET/HGETALL 适合字段级操作；LPUSH/RPOP 简单队列优于 BLPOP；ZADD 用时间戳作 score 支持范围查询。</p>
用 redis-cli 直连就能试，别急着写代码
多数人卡在第一步：连不上、命令输错、返回空或报错。直接开终端跑 redis-cli 是最快验证方式，不用配连接池、不用写客户端初始化。本地默认端口是 6379，连不上先检查 Redis 是否真在跑：redis-cli ping 返回 PONG 才算通。
常见错误现象：(error) NOAUTH Authentication required 说明启用了密码，得加 -a <password>；Could not connect to Redis at 127.0.0.1:6379 多半是服务没起来，或者用了 Docker 却忘了 -p 6379:6379 映射端口。
- 临时测试别用生产实例，
FLUSHDB会清空当前库所有 key - 中文或特殊字符存进去没问题，但用
KEYS *查时注意 shell 通配符会被提前展开，改用redis-cli --scan --pattern "*" - 想看数据结构类型？
TYPE <key>比猜靠谱，STRLEN对非 string 报错，LLEN对非 list 报错——类型错，命令就废
HSET 和 HGETALL 处理对象字段最省事
存用户信息、配置项这类“字段+值”结构，HSET 比塞 JSON 字符串强：字段可单独读写、不需序列化反序列化、内存更省。一个 HSET user:1001 name "Alice" age "28" role "admin" 就建好哈希表，HGETALL user:1001 拿全量，HGET user:1001 age 只取单个字段。
容易踩的坑：HSET 后续再设同 key 的不同字段，不会覆盖整个 hash，只更新指定字段——这点和 SET 完全不同；但 HGETALL 返回的是字段名和值交替的扁平列表（不是 JSON），程序里解析时注意成对取值。
- 字段名别含空格或冒号，虽然 Redis 不拦，但后续用正则或日志切分时容易出岔
- 如果字段值本身是 JSON 字符串（比如
tags: ["a","b"]），那就退化成 string 存，别硬塞进 hash——hash 适合原子字段，不适合嵌套结构 -
HLEN查字段数比HGETALL再算长度快得多，尤其大 hash
用 LPUSH/RPOP 做队列，别碰 BLPOP 除非真要阻塞
消息队列场景下，LPUSH job:queue {"id":123} 入队，RPOP job:queue 出队，简单可靠。Redis 本身不保证消费成功，所以业务逻辑得自己处理失败重推或死信。
为什么不用 BLPOP？它会在队列空时挂起连接，等新元素来才返回。开发调试时你敲完命令卡住不动，容易误以为崩了；线上若客户端网络抖动或超时设置不合理，可能堆积大量空闲连接，压垮 Redis 连接数上限。
- 批量入队用
LPUSH job:queue item1 item2 item3，比循环三次LPUSH快得多 - 想实现“优先级队列”？别改结构，用两个 key：
job:queue:high和job:queue:normal，消费者按顺序BLPOP两个 key（注意BLPOP key1 key2 timeout的 key 列表顺序就是优先级） -
LLEN查长度是 O(1)，但LRANGE取全部是 O(N)，大列表慎用
ZADD 时间戳当 score，天然支持按时间范围查
存带时间顺序的数据（如操作日志、排行榜、延迟任务），把毫秒时间戳当 ZADD 的 score，ZRANGEBYSCORE 就能直接按时间区间捞。例如：ZADD events:202405 1714567890000 "user:123 login"，然后 ZRANGEBYSCORE events:202405 1714567800000 1714567900000 拿到这一分钟内的所有事件。
别把 score 当唯一 ID 用：相同 score 允许多个 member，排序时 member 字典序决定先后——如果你依赖严格时间顺序，就得确保 timestamp 精确到毫秒且不重复，或者拼上唯一后缀（如 1714567890000:uuid）。
- score 支持浮点数，但别用
Math.random()这类小数——精度丢失可能导致ZRANGEBYSCORE漏数据 - 删除过期数据用
ZREMRANGEBYSCORE key -inf (1714567800000，注意括号表示“不包含”，避免删多 -
ZCARD查总数量是 O(1)，但ZCOUNT查某区间数量也是 O(log N + M)，M 是命中数，大数据量时别高频调
真正麻烦的是 score 设计：既要支撑查询维度（时间、权重、热度），又不能因为频繁更新 score 导致 zset 内部频繁重排。上线前拿真实数据量压测一下 ZADD 延迟，比凭感觉调优管用。
