商品详情页缓存键设计需围绕可读性、可管理、抗冲突、易失效四目标，采用“业务前缀+精确标识+可选维度”格式，如product:detail:{id}；按数据粒度拆分为基础信息、价格库存等独立键，并规避动态参数拼接、json作key、中文未编码等陷阱，大促前加版本号前缀，配合布隆过滤器防缓存穿透。
商品详情页缓存键设计不是拼凑字符串，而是围绕“可读性、可管理、抗冲突、易失效”四个目标来组织。键太长影响性能，太短又容易撞车；固定格式能统一治理，带业务语义便于排查问题。
核心原则：业务前缀 + 精确标识 + 可选维度
推荐格式：product:detail:{id} 或 product:detail:v2:{id}（v2代表版本号，用于灰度或结构变更）
不建议用 product_{id}_info 这类下划线+无意义分隔的写法——Redis命令行调试、监控平台展示、Key扫描都更难识别。
按数据粒度区分缓存键
详情页不是“一个接口一个键”，而是按模块拆分，方便局部更新和命中率优化：
-
基础信息键：如
product:base:1001—— 存商品名、主图URL、描述、类目ID等极少变动字段 -
价格库存键：如
product:price-stock:1001—— 存实时售价、SKU级库存、是否可售等，TTL设为30–120秒 -
销量评价键：如
product:sales-review:1001—— 存月销量、好评率、最新3条评价摘要，TTL可设为5–15分钟 -
推荐商品键：如
product:rec:1001:u123456—— 带用户ID后缀，用于个性化推荐（若需）；通用推荐可用product:rec:1001:common
规避常见陷阱
这些细节看似小，但高并发下会放大成故障点：
- 避免在键中拼接动态参数，如
product:detail:1001:uid_789（用户ID太多会导致Key爆炸）——改用本地缓存或客户端侧计算 - 不把JSON结构体直接当Key，比如
product:{"id":1001,"lang":"zh"}—— 序列化不稳定、长度不可控、无法复用 - 中文或特殊符号必须URL编码或转为ASCII，否则Jedis/Lettuce可能报错；推荐统一用英文+数字+冒号
- 大促前加版本号前缀，如
v2:product:detail:1001，方便一键清理旧结构缓存，不污染线上数据
配合使用布隆过滤器防穿透
对无效商品ID（如-1、abc、超长乱码），光靠Key不存在不够——大量恶意或错误请求仍会打到DB。应在缓存层之前加一层布隆过滤器，Key为 bloom:product:id，初始化时加载全量有效ID集合。查询前先过布隆器，不通过直接返回空，不查Redis也不查DB。
