Redis 键是应用的数据寻址约定。良好的键名让对象归属、类型、版本和环境一目了然，也让失效、排查和迁移可以按明确边界执行。常见结构为 服务:环境:实体:版本:标识，例如将租户与实体类型放在业务 ID 前。分隔符应固定，ID 应规范化，避免同一对象因大小写或格式差异产生多个缓存副本。
多租户环境必须把租户身份纳入键空间，或通过等价且可靠的隔离机制保证不同租户不会命中同一值。不能假定订单号、用户名或自然键在所有租户间全局唯一。键名尽量不包含姓名、邮箱、令牌等敏感信息；键通常会出现在诊断和监控上下文中。对用户控制的键组成部分设置字符集、长度和枚举限制，避免任意输入导致海量无效键。
TTL 应由数据可容忍陈旧时间与重建成本共同确定。商品展示信息和短期会话的变化频率不同，不适合统一时长。缓存写入时同步设置过期，避免程序异常路径留下永久键。热点键可给过期时间增加小幅随机抖动，降低大量键同时失效引起的后端重建尖峰。抖动解决的是集中到期，不会自动阻止单一热点键被并发请求重复重建。
TTL 不是源数据变更通知。如果业务要求变更后立刻生效，需要在写路径设计删除、覆盖、版本递增或事件驱动失效，并处理数据库提交成功而缓存更新失败的窗口。缓存重建时还要考虑旧请求晚到覆盖新值的竞态，可在值中携带版本或更新时间并验证写入顺序。过期策略和主动失效是两种不同职责。
在命名规范中定义每类键所存对象：单实体、分页结果、聚合结果或有界集合。为序列化值设置可接受大小范围，避免把大对象写入一个键而造成网络传输和内存分配尖峰。集合要规定最大成员数、成员过期方式和删除策略；若集合持续追加而没有边界，它就不再是可控缓存。队列、任务状态或重要计数可能承担可靠数据职责，应单独设计持久性、消费确认和故障恢复，不能因为也使用 Redis 就套用普通缓存的过期规则。
命中率提升不一定意味着缓存更健康：缓存了过大的低价值对象可能让内存增长，陈旧数据命中率再高也可能不符合业务。键数量长期增长、过期事件骤增、淘汰增加和内存碎片变化应结合观察。验收标准要同时包含租户隔离正确、陈旧窗口合规、键空间可治理、重建峰值可承受，以及关键队列和业务状态有独立边界。键名规范是数据模型的一部分，应随服务接口一起评审。
