最稳妥的动态Key设计是用fmt.Sprintf将确定性业务维度（如userID、标准化日期、pageNum）按固定格式拼接，统一用:分隔、%d/%s格式化、避免JSON/URL编码、过滤无关参数，并控制Key长度不超过256字节。

用 fmt.Sprintf 拼接多层业务参数最稳妥

动态 Key 的核心是把变化的业务维度（如用户 ID、时间范围、分页页码）稳定地转成字符串，且保证相同语义一定生成相同 Key。直接字符串拼接容易漏分隔符或类型转换出错，fmt.Sprintf 能强制类型对齐、显式控制格式。

常见错误现象：user:123:report:2024-05 和 user:123:report:2024-5 被当成两个 Key；或整数 ID 传了指针导致 %v 输出地址。

• 固定用 : 作分隔符，避免和业务数据冲突（比如用户名含下划线）
• 时间统一转为 2006-01-02 格式，不用 time.Now().Format() 直接拼，防止时区/精度干扰
• ID 类字段一律用 %d（整型）或 %s（已校验过的字符串），不混用 %v
• 示例：fmt.Sprintf("user:%d:report:%s:page:%d", userID, dateStr, pageNum)

别在 Key 里塞 JSON 或 URL 编码后的值

有人想“保险起见”把整个查询参数 map 序列化成 JSON 再当 Key 一部分，结果发现缓存命中率暴跌——JSON 字段顺序不固定、空格缩进不一致、浮点数精度差异都会让相同逻辑产生不同 Key。

URL 编码更危险：%20 和空格等价，但编码与否全看调用方，下游服务可能未解码就拼 Key。

• 只取确定性高的原始字段：ID、枚举值、标准化日期字符串
• 过滤掉非关键参数（如 trace_id、source 这类不影响结果的）
• 如果必须带模糊条件（如搜索关键词），先做归一化：strings.TrimSpace(strings.ToLower(keyword))

redis-cli --scan 查不到动态 Key？检查游标和匹配模式

用 SCAN 查动态 Key 时经常返回空，不是 Key 不存在，而是匹配模式写错了或游标没重置。Redis 的 SCAN 不支持通配符递归，* 只匹配单层，** 无效。

典型错误：SCAN 0 MATCH user:*:report:*:page:* 看似合理，但如果某次 Key 是 user:123:report:2024-05:page:1:extra，它就不会被匹配到。

• 匹配模式用 user:*:report:*:page:* 即可，末尾不加多余冒号或通配符
• 命令行执行时加 --scan 会自动处理游标，但首次必须从 0 开始，别手输错成 1
• 线上环境慎用 KEYS *，会阻塞 Redis；调试时优先用 SCAN + COUNT 1000

Key 太长或嵌套太深会影响性能和运维

见过最长的 Key 达到 512 字节：包含完整 URL、Base64 用户信息、毫秒级时间戳。这不仅拖慢网络传输，还让 redis-cli monitor 日志难以阅读，排查缓存穿透时根本没法快速定位模式。

Redis 对 Key 长度无硬限制，但实际中超过 256 字节就该警惕——序列化开销、内存碎片、集群 slot 计算都受影响。

• 去掉冗余前缀，比如 cache_user_report_v2_ 压缩为 u:r:
• 时间戳精确到天即可，除非业务真需要区分小时级缓存
• 用哈希摘要压缩长字段：md5.Sum([]byte(userID + "-" + dateStr))[0:8]（注意：仅用于 Key，勿用于安全场景）
• 示例优化后：u:r:7a3f9c1d:p:1（比 user:123456789:report:2024-05-20:page:1 短 62%）

Key 设计没有银弹，但所有复杂性都来自没想清楚“哪些变量真正影响缓存结果”。一旦开始往 Key 里塞 trace_id、request_id、随机 salt，基本就说明缓存策略本身需要重构了。