Redis Key必须用冒号分隔，因其是事实标准，支撑批量操作、工具识别与团队协作；层级建议3–4级且宽泛→具体，需校验落地防线上事故。
Redis Key命名为什么必须用冒号分隔
因为Redis本身没有命名空间概念，KEYS *、SCAN、监控、过期策略、甚至运维脚本都依赖Key的可解析结构。不用冒号，就等于放弃所有基于前缀的批量操作能力。
冒号是事实标准（不是强制规范），几乎所有Redis客户端库、管理工具（如RedisInsight）、缓存中间件（如Codis、Twemproxy）都默认按:切分层级。换其他符号（比如_或-）会导致工具识别失败、团队协作成本陡增。
- 冒号在ASCII中是可读分隔符，且不会和常见业务字符（字母、数字、下划线）冲突
- 避免嵌套层级过深：建议控制在3–4级，例如
user:profile:id:1001比app:v1:cache:user:profile:active:shard01:id:1001更易维护 - 层级顺序应从“宽泛→具体”：先域（
user），再类型（profile），再维度（id），最后值（1001）
如何避免Key命名引发的线上事故
最常踩的坑不是“怎么写”，而是“写完没人校验”——尤其当多个服务共用一个Redis实例时。
- 禁止在Key里拼接动态ID而不加约束：比如
order:status:<code>user_id:order_id，一旦user_id含冒号（如伪造ID或旧系统迁移数据），整个Key结构就崩了；应确保ID段只含字母数字，或提前replace(':', '_') - 不要把环境名硬编码进Key：比如
prod:user:1001。应靠连接池/配置隔离环境，否则本地调试一不小心就刷掉生产数据 - 避免使用Redis保留字做层级名：比如
redis:config:xxx或redis:slowlog:xxx，可能和运维命令冲突 - 所有Key必须带过期时间（
EXPIRE或SETEX），无TTL的Key=定时炸弹；临时调试用的Key务必加:tmp后缀并设5分钟过期
不同数据类型对应的Key命名习惯
Hash、ZSet、List这些结构天然有“容器”语义，Key名要体现“它装什么”，而不是“它叫什么”。名字不是标签，是契约。
-
hash存用户资料：用user:profile:<code>uid，别用user:info:<code>uid——profile比info更明确指代“结构化属性集合” -
zset做排行榜：用leaderboard:weekly:game_a，不写rank:week:game_a——leaderboard是领域术语，rank太泛，容易和user:rank（用户等级）混淆 -
list存消息队列：用queue:notification:sms:pending，而非sms_queue——后者无法区分环境、用途、状态，也难以做SCAN queue:notification:sms:*批量清理 -
string缓存计算结果：必须包含来源+参数摘要，比如cache:recommend:userid_1001:category_books:algo_v2，不能只写rec_1001
如何让Key命名规则真正落地不流于文档
靠人自觉不行，得进流程。最有效的手段是把校验变成开发环节的“硬门槛”。
- 在DAO层封装
buildKey()函数，禁止直接字符串拼接；例如Java里用UserKeyBuilder.of(1001).profile().toString()生成user:profile:1001 - CI阶段跑
redis-cli --scan --pattern "*:*:*" | grep -v ":" | wc -l检查是否存在非法Key（无冒号），失败则阻断发布 - 用Redis的
MONITOR命令抽样捕获Key写入流，结合正则匹配规则（如^[a-z]+:[a-z]+:(?:[a-z0-9_]+):[0-9]+$），发现不合规立即告警 - 给Redis配置
rename-command KEYS ""，逼所有人改用SCAN——而SCAN必须依赖前缀，倒逼命名规范
最难的不是设计规则，是让每个SET、HSET、ZADD调用都经过同一套构造逻辑。一旦放任自由拼接，三个月后你就得花半天时间解释为什么user_profile_1001和user:profile:1001指向不同数据。
