标准答案
- Key 应有稳定命名空间，例如 product:v2:{tenantId}:{productId}，把资源类型、版本、租户和业务主键按固定顺序表达。
- 多租户场景必须把已验证的租户上下文纳入 Key；不能直接相信客户端传来的 tenantId，也不能让不同租户复用同一个对象缓存。
- 版本前缀可用于字段结构或序列化协议升级，新旧读写在迁移期并存，完成后再清理旧版本，而不是让新代码尝试反序列化所有历史字节。
- 序列化格式要考虑体积、兼容性、调试性和安全性。跨服务对象应避免依赖语言私有序列化和不可信反序列化，字段演进要有默认值和未知字段策略。
题目解析
Key 设计本质是数据边界设计。省略租户、权限范围、语言或版本时，缓存很可能在后续扩展中出现串数据、读错语言或升级失败。
命名不应把敏感值直接拼入 Key，例如完整手机号、令牌或身份证号；既会泄露到监控和导出中，也会增加合规风险。
代码示例
版本和租户都应来自可信服务端上下文，示例只展示命名层次。
Text
product:v2:{tenant-42}:98765
profile:v3:{user-1001}
rate-limit:v1:{tenant-42}:{api:orders}常见误区
- 只用业务 ID 作为 Key，后续接入多租户后发生跨租户命中。
- 在 Key 中拼接完整敏感信息或未规范化的用户输入。