ASK错误是Redis集群槽位迁移过程中的临时重定向信号，表示目标key所在槽正从源节点迁往目标节点，源节点查不到该key时返回-ASK 12345 IP:PORT，客户端须先发ASKING命令开启REDIS_ASKING标识，再重试原命令，否则目标节点将拒绝执行并可能再次返回ASK错误。
ASK错误只发生在槽位迁移过程中
ASK不是配置错误或网络问题，而是Redis集群正在执行reshard（重新分片）的明确信号。它表示你访问的那个key所属的槽12345正处于从源节点向目标节点迁移的状态——部分数据还在源节点，部分已落到目标节点。源节点查不到该key时，就返回-ASK 12345 192.168.1.101:6379，告诉你“去那边试试”。
为什么你的客户端卡在ASK重试里出不来？
根本原因是客户端没按规范发送ASKING命令就直接重发原请求。Redis目标节点收到未带REDIS_ASKING标识的请求，哪怕槽号匹配，也会拒绝执行并可能再抛一次ASK——形成死循环。
- 用
redis-cli -c能绕过，是因为它内部自动补了ASKING - Jedis必须用
JedisCluster，不能用裸Jedis；后者不处理ASK流程 - Lettuce默认支持，但若手动构造连接、禁用了
clusterTopologyRefreshOptions，也可能跳过ASK处理逻辑 - Spring Boot中误配
spring.redis.host会强制降级为单机模式，彻底失去ASK感知能力
如何快速确认是否真在迁移中？
别猜，直接查集群状态：
redis-cli -c -h 192.168.1.100 -p 6379 cluster slots
看输出里是否有某槽同时出现在两个节点行中，并带importing或migrating标记；再查具体key归属：
redis-cli -c -h 192.168.1.100 -p 6379 cluster keyslot "your_key"
如果返回槽号，再用cluster getkeysinslot 确认该槽下key分布，就能定位是哪个节点在导出、哪个在导入。
生产环境最常被忽略的一点
ASK错误本身不可怕，可怕的是它和MOVED混在一起出现——比如迁移中途节点宕机、拓扑刷新失败、或cluster-require-full-coverage yes导致部分槽不可用。这时客户端可能先收到ASK，重试时又遇到MOVED，而某些老版本客户端（如Jedis 3.0以下）对双重重定向支持不完整，直接抛异常。务必检查cluster info里的cluster_state:ok和cluster_known_nodes数量是否一致。
