缓存键需包含站点标识、货币代码、业务上下文三要素，顺序固定、分隔明确，以实现多币种多地区独立缓存；典型格式如cache:site=jp:curr=jpy:product=456:price；须规避用户态、语言混用及原始汇率嵌入等陷阱。
缓存键设计要支撑多币种+多地区站点的独立缓存，核心是把“谁在哪儿、用什么货币、看什么内容”这三个维度稳定、无歧义地编码进键名里，避免不同地区用户看到错的价格，或同一商品在不同币种下缓存互相覆盖。
缓存键必须包含三个基础维度
一个安全可用的缓存键至少应组合以下三要素，顺序固定、分隔明确：
-
站点标识（site_id 或 domain）：如
us、jp、sa，优先用标准化的 ISO 3166-1 alpha-2 国家码；若支持多商户或多子域，可扩展为shopA.jp或brandX.fr -
货币代码（currency）：严格使用 ISO 4217 三位大写码，如
USD、JPY、SAR；注意不能用符号（如$）或小写（如usd），避免大小写混用导致重复缓存 -
业务上下文（context）：比如
product_123、category_home、cart_summary；对价格类数据，建议显式带上定价策略标识，如price_retail_USD或price_promo_JPY
典型缓存键示例与说明
以商品详情页价格片段为例，不同地区+币种应生成完全隔离的键：
cache:site=jp:curr=JPY:product=456:pricecache:site=sa:curr=SAR:product=456:pricecache:site=us:curr=USD:product=456:price
这种格式清晰可读、易于调试，也方便通过 Redis 的 KEYS cache:site=us* 快速扫描某站点全部缓存。不推荐用哈希（如 MD5）压缩键名——虽然节省长度，但丧失可追溯性和运维可观测性。
注意汇率变动带来的缓存失效策略
如果系统支持实时汇率浮动定价（非锁汇），那么价格缓存不仅要带币种，还需嵌入汇率基准时间点或版本号：
- 静态锁汇场景：订单创建时已锁定汇率，则缓存键中可加入
rate_ver=20260915_v2，表示该价格基于当日第2版汇率表 - 动态展示场景：前端需实时调用汇率服务，此时价格不应长期缓存，建议 TTL 控制在 60–300 秒，并配合后台异步刷新机制
- 严禁把原始汇率值（如
1 USD = 3.75 SAR）直接拼进缓存键——数值精度、四舍五入、浮点误差都会引发键不一致
避免常见陷阱
实际项目中最容易出问题的几个点：
- 用户登录态干扰：不要把
user_id或session_id塞进通用商品缓存键里——这会让缓存失去共享性，击穿率飙升 - 语言与货币混用：语言（
en）和货币（EUR）不是一一对应关系，德国站可选de+EUR或en+EUR，两者价格相同但文案不同，缓存键必须分开 - CDN 缓存协同：若用了 CDN 边缘缓存，需在请求头中透传
X-Site-ID和X-Currency，并在 CDN 规则中将它们设为缓存键组成部分，否则全球用户可能共用一个 HTML 片段
