订单详情接口返回的 user 字段变成了一串昵称和头像地址，排查发现订单服务和账号服务都往同一个 Redis db 写 user:1，类型还不一样。碰到这种情况，我一般先确认改动有没有真的生效。
原因不复杂，缓存 key 只有业务 id，没有服务名和数据类型前缀，两个服务刚好用了同一个格式。Redis 只按 key 存值，后写的直接把前一个覆盖。
碰到「缓存 key 冲突」这类问题，我习惯先把当前配置原样备份一份，改坏了立刻换回来，不用现场推。日志级别临时调高可以，记得改回去，长期开着既占磁盘又掩盖真问题。
SET app:order:user:1 ... SET app:account:user:1 ... # 前缀固定，禁止裸 user:1
权限不要一口气开到最大，先加到够用再往上试，范围小才好收。把复现步骤压到三条以内，交给同事也能跑出来，才算真的定位清楚。
具体做法是，key 统一加应用和服务前缀 例如 app:order:user:1；不同业务分 db 或分实例 不要图省事共用一个；上线前扫一遍现有 key 把无前缀的历史键列出来。
最后用这个标准收尾，订单接口的 user 字段恢复成用户 id，账号资料从账号服务读取正常，扫描无前缀 key 的结果为 0。