不推荐裸用 md5() 拼接参数，应采用结构化拼接+盐值+规范化参数顺序；php 中 md5(json_encode($params)) 因数组顺序、浮点精度、无盐值等问题易导致 key 不一致或缓存污染。
直接用 MD5 生成 Redis Key 容易撞哈希、难调试、不带业务语义，**不推荐裸用 md5() 拼接参数**。真正安全又可维护的做法，是结构化拼接 + 盐值 + 规范化参数顺序。
为什么裸调 md5(json_encode($params)) 会出问题
PHP 中常见写法：md5(json_encode($params)) 看似简单，但实际踩坑率极高：
-
json_encode()对关联数组和索引数组行为不一致，['a'=>1, 'b'=>2]和['b'=>2, 'a'=>1]编码结果不同 → Key 不一致 - 浮点数精度丢失（如
1.0可能变成1），null/''在 JSON 中表现相似但语义不同 - 没加盐值，相同参数在不同服务/环境生成的 Key 完全一样 → 误共享缓存、跨环境污染
- MD5 输出 32 字符，Redis Key 过长影响内存与网络开销（尤其高频小 Key 场景）
正确构造唯一 Key 的三步法（PHP 示例）
核心逻辑：**标准化 → 加盐 → 摘要截断**。以下函数可直接复用：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
function buildRedisKey(string $prefix, array $params, string $salt = ''): string
{
// 1. 参数标准化：ksort + 强制类型转字符串 + 过滤空值（按需）
ksort($params);
$normalized = [];
foreach ($params as $k => $v) {
$normalized[(string)$k] = is_scalar($v) ? (string)$v : json_encode($v, JSON_UNESCAPED_UNICODE | JSON_UNESCAPED_SLASHES);
}
// 2. 拼接前缀、标准化参数、盐值（盐建议用服务名或模块名）
$payload = $prefix . '|' . http_build_query($normalized) . '|' . $salt;
// 3. 用更安全的 hash（如 sha256），取前 16 字节转 hex（32 字符 → 16 字符）
return $prefix . ':' . substr(hash('sha256', $payload), 0, 16);
}
-
$prefix必填，体现业务域，如'user:profile'，避免 Key 冲突 -
http_build_query()比json_encode()更稳定：自动排序键、统一编码规则、不产生空格/换行 - 盐值
$salt建议设为常量，如APP_NAME或'v2'，升级算法时改盐即可批量失效旧 Key - 截取
substr(..., 0, 16)是平衡唯一性与长度的关键——SHA256 前 16 字节碰撞概率已足够低，且 Key 长度控制在 20 字符内
Redis Key 命名与摘要的兼容性陷阱
即使摘要逻辑正确，Key 设计不当仍会导致运维困难：
- 别把摘要当唯一标识来「解码」——
sha256是单向的，无法还原原始参数。调试时靠日志打点，不要试图反查 - 避免在 Key 中混用动态参数和静态标识，例如
'order:' . $id . ':cache'是好模式，而'cache:' . md5("{$id}_{$status}")把语义藏在哈希里，排查时完全不可读 - 如果参数含敏感字段（如手机号、token），**必须在标准化前脱敏或过滤**，否则摘要可能泄露信息（MD5 虽不可逆，但短输入易暴力破解）
- 高并发场景下，不要用
buildRedisKey()结果直接做SETNX锁 Key——摘要本身无序，多个请求可能生成相同 Key 导致锁竞争，应额外加随机后缀或用 Lua 原子控制
最常被忽略的一点：盐值不是“加个随机字符串”，而是要有明确生命周期管理。上线新版本、修复参数序列化 bug、切换哈希算法时，盐值就是你批量刷新缓存的开关——这个设计位，比选 MD5 还是 SHA256 更重要。
