缓存Key设计的“七要七不要”

要分层级，不要平铺直叙

• 口诀： 项目:模块:功能:ID
• 示例： taobao:item:detail:123 优于 item123
• 理由： 便于管理统计，避免不同业务Key冲突。

要固定参数顺序，不要直接拼接

• 口诀： 先排序，再哈希
• 示例： 查询参数先按字母排序（a=1&b=2），然后MD5作为Key。
• 理由： 解决?a=1&b=2和?b=2&a=1生成两个不同Key的问题，提升复用率。

要嵌入版本号，不要原地修改

• 口诀： 旧数据让它静默过期
• 示例： 升级数据结构时，写入user:v2:123，旧user:v1:123自然失效。
• 理由： 防止代码升级后读取旧缓存导致反序列化报错。

要区分动静数据，不要混为一谈

• 口诀： 高频变和低频改要分开
• 示例： 商品详情（缓存久）和商品库存（不缓存或极短缓存）分开存。
• 理由： 避免修改频繁的字段导致整个大缓存频繁失效。

要脱敏处理，不要明文暴露

• 口诀： 手机号、身份证号必须哈希
• 示例： index:phone:md5(13800138000) 而不是 phone:13800138000。
• 理由： 防止日志泄露用户隐私，防止Redis被入侵后直接拖走明文敏感数据。

要控制长度，不要大而不当

• 口诀： Key名要精简，百字节以内
• 示例： 能用user:123:avatar就不用user_profile_image_12345_2024_version_3。
• 理由： 过长的Key占用内存，降低查询效率，易被利用进行内存攻击。

要防止穿透，不要有“万能Key”

• 口诀： 对非法ID也要缓存空值
• 示例： 查询item:-1，数据库没有，缓存一个item:-1=null并设置短过期。
• 理由： 防止恶意使用不存在的ID频繁穿透数据库。