前言

购物车看起来简单，但它连接用户、商品、价格、库存和订单。面试常问：

  • 未登录购物车怎么存。
  • 登录后怎么合并。
  • 购物车用 Redis 还是数据库。
  • 商品下架或价格变了怎么办。

存储方案

方案 优点 缺点
Cookie/LocalStorage 未登录可用 容量和安全有限
Redis 快，适合高频读写 要处理持久化
数据库 持久可靠 访问频繁时压力大
Redis + DB 性能和可靠性兼顾 实现复杂

企业里常用：未登录存在客户端，登录后同步到服务端 Redis 或数据库。

登录合并

合并规则：

  • 同商品 SKU 合并数量。
  • 以最新选择状态为准。
  • 校验商品是否有效。
  • 数量不能超过限购和库存。
flowchart TD
    A[未登录购物车] --> C[登录合并]
    B[服务端购物车] --> C
    C --> D[按 SKU 合并]
    D --> E[校验商品/库存/价格]
    E --> F[保存合并结果]

商品失效

购物车展示时要实时校验：

  • 商品是否下架。
  • SKU 是否存在。
  • 价格是否变化。
  • 库存是否不足。
  • 活动是否结束。

购物车里保存的是快照，结算时必须重新校验实时价格和库存。

Redis 结构

常见 key：

1
cart:{userId}

Hash 结构：

1
2
field: skuId
value: 商品数量、勾选状态、加入时间

高频面试题

购物车价格以什么时候为准？

以下单结算时实时价格为准，购物车展示价格只是参考。

未登录购物车为什么不能只放服务端？

服务端无法稳定识别匿名用户，通常先存在客户端，登录后再合并。

购物车数据会不会丢？

如果只存在 Redis，极端情况下可能丢；重要业务可以异步落库或定期持久化。

合并购物车怎么处理冲突？

按 SKU 合并数量，并校验限购、库存和商品状态。

总结

购物车场景的关键是客户端和服务端协同、登录合并、商品实时校验、Redis 高效存储和下单前重新确认。不要把购物车里的价格和库存当作最终交易依据。