HGETALL在千万级Hash下会彻底阻塞Redis主线程，导致所有请求延迟突刺、连接堆积和内存瞬时翻倍；必须用HSCAN分批迭代（COUNT=500）、游标原样传递、客户端驱动循环，且需业务层容忍最终一致性。
Redis单线程模型下HGETALL会彻底阻塞后续所有请求
Redis处理命令是严格串行的，HGETALL执行期间主线程无法响应任何其他请求。千万级Hash字段意味着它要遍历、序列化、打包并返回数百万个field-value对——这个过程不是毫秒级，而是秒级甚至更长。一旦发生，所有客户端连接都会卡在read timeout，监控上表现为P99延迟突刺、连接堆积、慢日志里反复出现HGETALL超时记录。
HGETALL内存开销翻倍且不可控
HGETALL内部必须把整个Hash结构一次性加载进内存，构建为一个临时Lua表（若在脚本中调用）或协议响应体（若直连调用）。实测500万字段的Hash，原始数据约80MB，但HGETALL触发后Redis内存瞬时上涨160MB+，极易触达maxmemory限制，报错command not allowed when used memory > 'maxmemory'。这不是配置调大就能解决的问题，而是设计上就拒绝流式传输和分批释放。
HSCAN才是千万级Hash唯一可行的遍历方式
用HSCAN替代HGETALL不是“性能稍差但更稳”，而是“唯一能跑通”的方案：
-
HSCAN每次只拉取COUNT量级的数据（建议设为500），响应包小、内存可控、不触发主线程阻塞 - 游标
cursor必须原样传递，不能tonumber()再转回字符串——Redis 6.0+的游标可能是base64编码的大整数 - 客户端需自行循环驱动，直到返回
cursor == b'0'（注意是字节串，不是字符串'0'） - 并发修改Hash时，
HSCAN可能重复或漏掉部分field，这是设计使然，业务层需容忍最终一致性
真正危险的不是“用了HGETALL”，而是“没意识到它正在悄悄膨胀”
很多团队出问题前根本不知道自己有千万级Hash：字段数从几千涨到几百万，往往发生在用户标签、设备画像、订单快照等长期累积型业务里。等到慢日志报警、CPU打满、客户端OOM才去查，已经晚了。最该做的不是事后优化，而是上线前就禁用HGETALL、在CI里加Redis命令白名单检查、对Hash key定期用DEBUG OBJECT key抽查编码类型和字段数——这些动作比写一个完美的HSCAN循环重要得多。
