获课：xingkeit.top/5269/

React 购物车组件开发：本地存储与后端同步的双重保险

购物车是电商系统中最复杂的前端组件之一——它不仅要实时响应用户操作，还要在离线、切换设备、清除缓存等极端场景下保住数据。纯本地存储怕丢数据，纯后端同步怕网络卡顿，最优解是两者结合：本地先响应用户，后台默默同步。

架构设计：本地为王，后端兜底

整个购物车的数据流分为三层：

第一层是 UI 层，用户看到的商品列表、数量增减、全选反选、价格合计，全部从本地状态读取。用户点击"加购"的那一刻，界面必须在 50 毫秒内响应，不能等网络。

第二层是本地存储层，用 localStorage 持久化购物车数据。选择 localStorage 而非 sessionStorage，是因为用户关闭浏览器再打开，购物车不应该清空。数据结构不要只存商品 ID 和数量，要把商品标题、单价、规格、选中状态一并存下——这样即使后端接口暂时不可用，前端也能完整渲染。

第三层是后端同步层，通过接口把本地购物车推送到服务器。同步策略不是每次操作都请求后端，而是采用"防抖 + 增量同步"——用户停止操作 500 毫秒后，把本地最新状态一次性推送；如果网络恢复，再把离线期间的变更批量补发。

同步策略：解决"谁说了算"的问题

本地和后端数据不一致是最大的坑。用户在手机上加了商品，回到电脑上发现购物车是空的——这种体验直接劝退。

以本地为单一数据源（Source of Truth） 是最简单也最可靠的策略。本地状态永远是最新的，后端只是备份。页面加载时，先读 localStorage 渲染 UI，同时异步拉取后端数据。如果两者一致，跳过；如果后端有新数据（比如用户在另一台设备上加了商品），以后端为准覆盖本地，并触发一次 toast 提示。

合并逻辑是关键。 不能简单地用后端数据覆盖本地，因为用户可能在本地删除了某个商品，而后端不知道。正确做法是对比两边的商品 ID 列表：本地有后端没有的，保留本地删除操作；后端有本地没有的，追加到本地；两者都有但数量不同的，以后端为准——因为后端包含了库存校验的结果，本地的数量可能已经超卖。

增量同步与冲突处理

全量同步每次都传整个购物车，带宽浪费且容易超时。增量同步只传变化的字段：新增传商品 ID 和数量，删除传商品 ID，修改传商品 ID 和新数量。

冲突处理靠时间戳。 每次本地数据变更时，记录一个版本号或时间戳。同步时带上这个版本号，后端比对：如果后端版本更新，说明有其他设备修改过，以后端为准；如果本地版本更新，说明是当前设备的操作，以后端确认接收为准。这个机制能覆盖 99% 的多设备冲突场景。

性能与体验的平衡

localStorage 的读写是同步阻塞的，购物车数据量大时会卡主线程。解决办法是把购物车数据拆成两份：高频变化的字段（数量、选中状态）放 React state，只在用户停止操作或页面卸载时写入 localStorage；低频字段（商品信息）直接从 localStorage 读取，用 useMemo 缓存解析结果。

页面卸载时的同步不能靠 beforeunload——这个事件在移动端几乎不可靠。更稳妥的做法是用 navigator.sendBeacon 在页面关闭前发送最后一次同步请求，或者用 Service Worker 在后台完成同步。

核心原则

本地存储保证体验，后端同步保证可靠。两者不是竞争关系，而是主从关系。本地永远快一步，后端永远兜住底。把这个逻辑想清楚，购物车组件就不只是一个 UI，而是整个电商链路中最坚固的那一环。