Redis Key 设计也需要规范

Redis 用起来很轻，但 key 设计如果随意，后面排查会很痛苦。不同模块各写各的命名方式，缓存内容没人知道来源，过期策略不统一，最后 Redis 会变成一个难以治理的黑盒。

命名要能看出归属

一个 key 最好能看出业务域、数据类型和定位字段。这样排查时看到 key，就能大致知道它属于哪个模块、存的是什么、应该找谁确认。

命名不需要追求花哨，但要稳定。不要今天用 user，明天用 account，后天又拼中文。规范的价值不在于好看，而在于团队能长期读懂。

不是所有 key 都应该永久存在。验证码、临时令牌、查询缓存、统计快照，它们都有不同生命周期。写入 key 时如果忘记过期时间，后面很容易形成垃圾数据。

我更倾向于在封装方法里强制传入过期策略，避免业务代码随手 set。这样可以把风险前置到开发阶段。

缓存内容也要考虑可读性。简单字符串、哈希结构、列表结构各有适用场景。为了排查方便，缓存对象最好不要塞入难以识别的压缩内容，除非确实有性能或空间要求。

如果内容经过序列化，也要保证字段变化有兼容策略。否则发布后旧缓存反序列化失败，会变成很隐蔽的问题。

Redis key 设计不是小事。它影响开发协作、线上排查、容量治理和故障恢复。越是常用的基础组件，越需要朴素但稳定的规范。