缓存键大小写敏感导致重复缓存，需通过统一工具函数强制归一化字符串字段为小写、数字字段保持原样，并配合Redis CLI验证、日志对比和单元测试覆盖边界用例来提前拦截。
缓存键大小写敏感导致重复缓存，本质是同一业务语义的数据被生成了多个不同键（如 user_123:profile 和 USER_123:PROFILE），造成冗余存储、命中率下降，甚至数据不一致。排查关键不在“发现异常”，而在“提前拦截+可验证设计”。
统一入口做标准化处理
所有缓存键生成必须经过一个可控的工具函数，禁止在各处手拼字符串。该函数应强制执行大小写归一化：
- 用户 ID、租户 ID 等数字型字段保持原样（本身无大小写问题）
- 用户名、邮箱、路径等字符串字段，统一转小写（
username.toLowerCase()）或使用规范化哈希（如sha256(email.trim().toLowerCase())） - 业务类型前缀（如
profile、settings）也统一小写，避免Profile和profile并存
用 Redis CLI 快速验证键分布
上线后或问题复现时，直接连接 Redis，用模式匹配查看实际键名是否收敛：
-
KEYS user_*:profile—— 检查是否存在user_123:PROFILE、user_123:Profile等变体 -
SCAN 0 MATCH user_*:* COUNT 1000—— 更安全地抽样，配合本地脚本统计后缀出现频次 - 若发现同一用户 ID 对应多个 profile 后缀，说明键生成逻辑未归一
日志中记录原始输入与最终键
在缓存读写操作日志里，同时打印原始参数和最终生成的键（脱敏处理）：
- 例如：
[cache:get] raw={userId:123, name:"Admin"} → key="user_123:profile" - 对比不同请求的日志，能快速定位是哪个字段（如 name、role）未标准化就参与了拼接
- 特别注意 HTTP Header、Query Param、Body 字段——它们最容易带大小写差异且被忽略
单元测试覆盖大小写边界
为键生成函数写明确的测试用例，不只测正常值，更要覆盖典型干扰项：
generateKey({ userId: 456, name: "JOHN" }) → "user_456:profile"generateKey({ userId: 456, name: "john" }) → "user_456:profile"generateKey({ userId: 456, name: "John" }) → "user_456:profile"- 失败即报错，不接受“看起来差不多”的模糊通过
