日期：2026-07-11
标签：#面试 #八股 #后端 #系统设计 #购物车 #场景题
一句话答案
购物车保存用户购买意图而非商品事实，按用户分片存储 SKU、数量和选中状态，展示时实时或批量获取最新价格、库存与促销，下单时再次校验。
面试口语版
核心接口包括加商品、改数量、删除、勾选、列表和结算预览。登录用户购物车按 userId 存数据库，Redis 做缓存；游客用设备 token 存本地或服务端，登录后按规则合并。购物车只保存 skuId、数量、选中状态、加入时价格等快照，商品名称、现价、库存和优惠由商品/营销服务批量返回。更新使用版本号或按 SKU 幂等 upsert，限制 SKU 数和数量。结算不信任购物车缓存，必须重新校验价格、库存、限购和优惠。
数据模型
cart_item(user_id, sku_id, quantity, selected, added_price, version, updated_at)
唯一键：(user_id, sku_id)关键细节
- 列表批量获取商品信息，避免每个 SKU 一次 RPC。
- 缓存与数据库可采用 Cache Aside，更新后删除缓存或版本化。
- 跨端修改存在覆盖，使用 item 级更新时间/版本合并。
- 失效商品保留并标记，方便用户理解而非静默删除。
面试官追问
- 游客购物车登录后如何合并？
- 购物车价格与下单价格不一致怎么办？
- 如何支持购物车跨端同步？
面试官追问参考答案
1. 游客购物车登录后如何合并？
以 skuId 合并，数量可相加后受限购上限约束，选中状态按产品规则处理；已失效商品保留标记。合并请求带一次性 token 和幂等键，成功后删除游客购物车，重复请求返回同一结果。
2. 购物车价格与下单价格不一致怎么办？
购物车价格仅用于展示或记录加入时快照，结算和创建订单必须以价格服务实时计算为准。价格变化要明确提示用户并要求确认，订单保存最终价格明细，不能由客户端传价。
3. 如何支持购物车跨端同步？
服务端数据库是事实源，各端提交 item 级变更并携带版本或更新时间，服务端原子更新后返回新版本。客户端通过增量接口或推送拉取变更，冲突可按服务端时间、操作类型和业务规则合并。
学习清单
- 区分购物车意图数据和商品事实数据。
- 能说明游客合并、价格校验与跨端同步。
Maintained by · YihuiEdit on GitHub