Hash 是购物车的首选结构，因其以用户ID为Key、商品ID为Field、数量为Value，支持单字段原子操作（如HINCRBY）、避免全量读写与并发覆盖，且内存更紧凑。
为什么用 HASH 而不是 STRING 或 SET
用户购物车本质是「一对多」的键值映射：一个用户（user:123）对应多个商品（item:456 → 数量 2，item:789 → 数量 1）。HASH 天然适合这种结构——顶层 Key 是用户 ID，每个 field 是商品 ID，value 是数量（或 JSON 字符串存更多字段）。相比 STRING（需序列化整个 cart）、SET（无法存数量）、LIST（去重/更新低效），HASH 支持原子增减、单字段读写、批量操作，且内存更紧凑。
HINCRBY 增加商品数量时要注意什么
直接用 HINCRBY 更新数量最常用，但容易忽略两个边界：
- 如果商品第一次加入，
HINCRBY会自动创建 field 并从 0 开始加，没问题； - 但如果传入负数导致数量 ≤ 0，Redis 不会自动删除该 field，得手动
HDEL，否则脏数据残留； - 并发场景下，多个请求同时
HINCRBY user:123 item:456 1是安全的（Redis 单线程保证原子性），但「先查再判再增」这类逻辑必须用 Lua 脚本封装，否则有竞态。
推荐做法：用 Lua 保证「增后为 0 则删」：
eval "local n = redis.call('HINCRBY', KEYS[1], ARGV[1], ARGV[2]); if n <= 0 then redis.call('HDEL', KEYS[1], ARGV[1]) end; return n" 1 user:123 item:456 -1
商品信息存在 Hash value 里还是单独查 DB
Hash 的 value 只建议存轻量数据，比如纯数字（数量）、简单字符串（SKU 编码）、或极简 JSON（{"qty":2,"selected":true}）。不要把商品名称、图片 URL、价格等动态易变字段硬编码进 value —— 这些应始终以商品 ID（field）为线索，实时查 MySQL 或缓存好的商品元数据。原因很实际：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 价格变更时，要遍历所有用户 Hash 更新 value，成本爆炸；
- Hash value 过大（>1KB）会显著拖慢
HGETALL和网络传输； - 不同用户看到的价格可能不同（会员价、地域价），服务端必须动态计算。
典型组合：Redis 存 user:123 → { "1001": "2", "1002": "1" }，接口返回购物车时，用 HKEYS user:123 拿出 ID 列表，再批量查 DB 补全详情。
如何处理登录态切换和游客购物车合并
游客用随机 token（如 UUID）当用户 ID 存 Hash，登录后要把 cart:abc-xyz 合并到 user:789。关键点是「合并时数量叠加，不覆盖」：
- 用
HGETALL cart:abc-xyz拿游客数据，再逐个HINCRBY user:789 {item_id} {qty}； - 别用
HMSET直接覆盖，否则已登录用户的原有商品会被清掉； - 合并完记得
DEL cart:abc-xyz，避免重复合并； - 如果游客 cart 很大（>1000 商品），分批操作，防止单次命令阻塞 Redis。
真正麻烦的是冲突策略：游客加了商品 A，登录后用户已有商品 A 且数量不同，按「取大」还是「相加」？这得由业务定，但 Redis 层只负责执行，别在存储层做业务判断。
Hash 做购物车不难，难的是数量更新的原子性、数据一致性边界、以及和下游 DB 的协作节奏。很多线上问题其实不出在 Redis 用法，而出在「以为 value 里多塞点字段就省事」，结果改个价格全量扫 key，或者合并逻辑漏删游客 key 导致重复加购。
