string适合单值高频读写，字段更新需全量覆盖；hash支持字段级原子操作但有内存放大风险；字段读写频率差异大时宜混合使用；hash不支持字段级过期，整体过期选string。
String适合单值高频读写，但字段更新必须全量覆盖
当你缓存的是一个不可拆分的原子值——比如 session_id、captcha_code、feature_flag，用 SET/GET 就是最优解。Redis 对 String 的操作是 O(1)，内存结构最紧凑（一个 redisObject + 一个 SDS），没有额外字段管理开销。
常见错误现象：
- 把用户资料塞进 JSON 字符串存在
user:1001里，然后每次改头像都GET→ 反序列化 → 改avatar_url→ 序列化 →SET - 并发时出现字段覆盖：A 读取后改
name，B 同时读取后改age，B 的SET把 A 的name覆盖掉了
实操建议：
- ✅ 单值、只读或极少更新的场景（开关、token、计数器）坚定用
String - ❌ 不要用
String存多字段对象，除非该对象生命周期内几乎不更新 - ⚠️ 已上线的 JSON
String若开始出现更新冲突或延迟毛刺，别修修补补，直接评估切Hash
Hash支持字段级原子操作，但小字段多时有内存放大风险
HSET、HGET、HINCRBY 这些命令能直接命中某个 field，不碰其他字段。适合“一个 key 对应多个可独立读写的字段”的场景，比如用户资料、商品属性、配置分组。
但它不是无代价的：Redis 默认对字段数 ≤ 512 且每个 value 长度 ≤ 64 字节的 Hash 使用 ziplist 编码——内存极紧凑；一旦越界，自动转成 hashtable，内存可能翻倍甚至更高。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
实操建议：
- ✅ 字段数适中（
10~200）、单field值较短（如城市名、状态码、时间戳）→ 优先用Hash - ❌ 字段上千个（如日志 tag 映射表）或单
field存 base64 图片/大文本 → 改用独立Stringkey 或其他结构 - ⚠️ 上线前务必用
MEMORY USAGE user:1001对比同数据下String(JSON)和Hash的实际占用，别凭感觉
字段读写频率差异大时，混合结构比硬选一种更靠谱
真实业务里，一个用户对象常有“高频字段”（last_login_time、status）和“低频字段”（bio、avatar_url）。全塞 Hash 会让低频大字段拖慢 ziplist 编码效率；全拆 String 又导致 key 数暴增、关联性丢失、运维成本上升。
实操建议：
- ✅ 核心高频字段（≤ 5 个）放
Hash，保障原子更新和带宽节省 - ✅ 大文本/低频字段（如
avatar_url、introduction）单独用Stringkey 存储，加独立过期策略 - ⚠️ 混合结构要统一命名规范，比如
user:1001:profile（Hash）、user:1001:avatar（String），避免后期混乱
Hash不能设整体过期时间，String天然支持
EXPIRE 只能作用于整个 key，而 Hash 是一个 key 下多个 field，Redis 不提供 “给某个 field 设过期时间” 的能力。这意味着：如果你需要“用户资料 24 小时后全部失效”，String（存 JSON）天然支持 EXPIRE user:1001 86400；而 Hash 必须靠应用层定时清理或依赖 TTL 到期后整个 key 消失——但你可能只想让 avatar_url 过期，name 和 age 还要留着。
实操建议：
- ✅ 整体生命周期一致、需统一过期的对象 → 选
String - ✅ 需要部分字段长期有效、部分字段短期有效 → 必须拆开，用不同 key + 不同
EXPIRE - ⚠️ 不要试图用
Hash模拟字段级过期（比如存时间戳再应用层判断），这会把一致性逻辑推给业务代码，容易出错
Hash，如果其中一个是 70 字节的 base64，就可能触发编码升级，内存瞬间膨胀——这点在压测时很难暴露，得靠 MEMORY USAGE 实测。
