MGET在Redis集群中报CROSSSLOT错误是设计使然，因命令需原子执行且仅限单槽；必须用一致HashTag（如{user:1001}）强制相关key落入同一slot，否则无法批量读取。
MGET 在 Redis 集群中直接报 CROSSSLOT Key in different slots，不是 bug，是设计使然——集群不允许跨槽批量读。 你得主动让多个 key 落在同一个 slot，而不是指望客户端或框架自动拆分或重试。
为什么 MGET 会触发 CROSSSLOT 错误
Redis 集群把 16384 个 slot 分配给不同节点，MGET 是原子命令，必须由单个节点执行。一旦传入的 key 经 CRC16(key) % 16384 算出的 slot 不一致，节点就拒绝执行并返回错误。
常见踩坑点：
- 用
user:1001和user:1002直接MGET→ 几乎必然跨槽 - Hyperf 的
Redis::mget()或$redis->mget()默认不干预 key 分布，原样转发 - 加了
cluster => true配置但没改 key 结构，错误照旧
用 HashTag 强制共槽：{xxx} 是唯一可靠手段
Redis 规定：只取 { 和 } 包裹的第一段字符串参与 CRC16 计算，其余部分被忽略。这是协议层支持的机制，不是客户端 hack。
实操建议：
- 把业务上需要批量读的 key，统一加上相同 HashTag 前缀，例如：
{user:1001}.profile、{user:1001}.settings、{user:1001}.stats - Tag 内容必须完全一致（大小写、冒号、数字都不能差），否则 slot 不同
- 避免嵌套
{，Redis 只识别第一个{到第一个}之间的内容 - 不要用
{user_id}这种动态 tag —— 如果 user_id 来自变量，需确保拼接后字符串稳定可预测
验证方式（PHP CLI）：
php -r "echo crc16('{user:1001}.profile') % 16384 . \"\n\"; echo crc16('{user:1001}.settings') % 16384 . \"\n\";"
两个输出应完全相同。
Hyperf 中的实际调用写法
Hyperf 的 Redis 组件默认走 phpredis 或 predis，只要 key 命名合规，MGET 就能过。
示例（在 Service 或 Command 中）：
$keys = [
'{user:1001}.profile',
'{user:1001}.settings',
'{user:1001}.stats',
];
$values = $this->redis->mget($keys); // ✅ 正常返回
注意：
- 别在 key 外层再套逻辑（如用
str_replace动态加{}），容易漏掉或错位 - 如果已有存量 key（如
user:1001:profile），迁移时需双写 + 渐进式切换，不能直接改名丢数据 - Hyperf 的连接池和重试配置（如
retry_interval）对CROSSSLOT无效——这不是网络错误，是语义拒绝
替代方案对比：什么时候不该硬上 HashTag
HashTag 简单有效，但有副作用：所有带同一 tag 的 key 永远挤在一个 slot，可能造成热点。如果批量操作只是偶发、key 关联性弱、或数量极大，考虑这些路子：
- 拆成多次单 key
GET：用 Hyperf 的协程并发（Co::parallel）发起多请求，性能损失可控，且无槽位约束 - 用 Lua 脚本封装：脚本内逐个
GET并return数组，仍受限于“脚本必须在单一 slot 执行”，所以 key 还得共 tag - 放弃集群，改用单节点 Redis：仅适用于中小流量、可用性要求不苛刻的场景
真正难处理的是“跨业务实体的批量读”，比如同时查用户、订单、商品信息——这类需求本质上就不适合集群的 MGET，该拆服务就拆，别硬塞一个 key 前缀里。
