在做电商项目的时候。有一个看起来很小的问题：使用者在商品页加了一件东西进购物车，Header 右上角的数字要 +。

这个需求本身不复杂，但我在三个不同的项目里见到了三种完全不同的解法。每一种解法背后都是一套不同的架构决策——状态到底归谁管？

这篇文章是我在读 Medusa源码时引发的思考，整理了我对这个问题的理解过程。

先定义清楚这个问题

“Header 购物车数字怎么更新”。本质上是一个跨组件状态同步问题：

商品页的"加入购物车"按钮 ↓ 购物车数量变了 ↓Header 的数字组件（响应方)

这两个组件在页面上没有直接的父子关系，但需要共享同一份数据。老实说，

不同架构对这个问题的回答。决定了整个前端的数据流长什么样。

解法一这方面，客户端拥有状态

方案描述

在一个 Monorepo 单体前端项目里一种常见的做法是用 useReducer + SessionStorage 来管理跨页面的状态：

// 环境：React + Next.js
// 场景：用 useReducer 管理 cart 状态。并持久化到 SessionStorage
type CartState = {
至于items，CartItem
totalCount: number
}
type CartAction =
| { type: 'ADD_ITEM';payload: CartItem }
| { type: 'REMOVE_ITEM';payload: string }
| { type: 'INIT';payload: CartState }
function cartReducer: CartState {
switch {
case 'ADD_ITEM':
return {
...state,items:,totalCount: state.totalCount + action.payload.quantity,}
case 'REMOVE_ITEM':
return {
...state,items: state.items.filter,totalCount: state.totalCount - /* TODO: quantity */,}
case 'INIT':
return action.payload
default:
return state
}
}
// 每次 dispatch 同步写入 SessionStorage
function useCartWithSession {
const = useReducer
const persistedDispatch = => {
dispatch
const nextState = cartReducer
sessionStorage.setItem)
}
// 页面初始化时从 SessionStorage 读取
useEffect => {
const saved = sessionStorage.getItem
if {
persistedDispatch })
}
}。)
return { state,dispatch: persistedDispatch }
}

数据流：

使用者点击"加入购物车"
↓ dispatch
↓ reducer 更新内存中的 state
↓ 同步写入 SessionStorage
↓ 所有订阅了这个 context 的组件重渲染
↓ Header 数字更新

这个方案在做什么

状态存在客户端的内存和 SessionStorage里。内存保证当前页面的响应速度，SessionStorage 保证页面跳转后状态不丢失。

组件间的同步靠 React Context——谁订阅了这个 context，谁就能感知到 dispatch 触发的变化。

权衡

优势：

• 直觉清晰，数据流可追踪
• 不依赖网络，操作响应快
• 状态变化立即反映在 UI

代价：

• 需要手动管理“内存状态”和“持久化状态”的同步
• If multiple tabs are open。状态会不一致（使用者痛点：跨标签页购物车数字不同步导致购买冲突)
• 客户端状态和服务端实际数据可能出现偏差

至于解法二，消灭状态

在另一个电商项目里前端是微前端架构——PDP、Cart、Checkout 各自是独立部署的应用，挂载在一个 CMS的页面上。

This architecture eliminates “cross‑component state sync” problem because re is no single global front‑end.

CMS Shell
├── /products/ → PDP 微前端
├── /cart → Cart 微前端
└── /checkout → Checkout 微前端

The only bridge 娱乐ween apps is URL:

// 环境：微前端。PDP 应用
// 场景：加购后跳转到 Cart，通过 URL 传递 cart_id
async function handleAddToCart {
// 调用 cart-service 创建或更新 cart
const response = await fetch('/api/cart',{
再看method，'POST',body: JSON.stringify,})
const { cartId } = await response.json
// 跳转到 Cart 微前端，通过 URL 参数传递 cart_id
window.location.href = `/cart?cart_id=${cartId}`
}
// Cart 微前端初始化时从 URL 中读取 cart_id
function CartApp {
const cartId = new URLSearchParams.get
useEffect => {
if {
// 用 cart_id 查询购物车数据并渲染页面
fetchCartData
}
}。)
}

使用者在 PDP 点击"加入购物车"
↓ 调用 cart-service API，拿到 cart_id
↓ 跳转到 /cart?cart_id=xxx
↓ Cart 微前端用 cart_id 初始化并 fetch 数据

The architecture removes need for a “global state manager”. Each micro‑frontend owns its own data;communication happens via physical boundaries .

The Header’s shopping‑cart number belongs to CMS shell – it’s outside scope of any micro‑frontend.

• Simplified boundaries – each app only cares about its own domain.
• No state pollution across apps;independent deployment and maintenance.
• Diverse tech stacks can coexist.

• The global experience suffers – who updates Header’s number?
• Cumbersome cross‑app communication;URLs can only carry limited data.
• EACH navigation triggers a full page load,hurting perceived performance.

从解法三来看，服务端拥有状态

The Medusa source reveals that Cart does **not** use a React Context at all. Instead it relies on Next.js server actions and cache invalidation:

// 环境：Next.js App Router，Server Action
// 来源：Medusa nextjs-starter-medusa/src/lib/data/cart.ts
export async function addToCart({
variantId。quantity,countryCode,}: {
variantId: string
quantity: number
countryCode: string
}) {
// 确保 cart 存在没有就创建，并把 cart_id 写入 cookie
const cart = await getOrSetCart
if throw new Error
// 调用 Medusa API 写入数据
await sdk.store.cart.createLineItem(
cart.id,{ variant_id: variantId,quantity },{},headers,).n => {
// 操作成功后让相关缓存失效
const cartCacheTag = await getCacheTag
revalidateTag // Cart 数据缓存失效
const fulfillmentCacheTag = await getCacheTag
revalidateTag // 履约数据缓存失效
})
// 注意：没有返回值，仅负责写库并触发缓存失效。}

The flow looks like this:

使用者点击"加入购物车"
↓ Client Component 调用 addToCart
↓ getOrSetCart — 确保 cart 存在cart_id 写入 cookie
↓ sdk.store.cart.createLineItem — 调 Medusa API 写库
↓ revalidateTag — 标记对应缓存失效
↓ Next.js 自动重新 fetch 所有标记了 "carts" tag 的数据
↓ Header 数字、Cart 页面列表同时自动更新 

The persistent identifier :

// 环境：Next.js Server Action
async function getOrSetCart {
let cart = await retrieveCart
if {
// 创建新 cart 并写入 cookie
const resp = await sdk.store.cart.create(
{ region_id: region.id },{},headers。)
cart = resp.cart
await setCartId // 写入 cookie，而非 URL
const tag = await getCacheTag
revalidateTag // 同时让缓存失效触发 UI 更新
}
return cart
}

This solution in practice

• The **single source of truth** lives on server.
• The front‑end only holds a lightweight `cart_id` .
• If any component reads same cache tag,Next.js guarantees y see consistent data after invalidation.
• No explicit “notify or components” code is needed – cache does it for you.

• No manual sync logic;Next.js handles cache invalidation automatically.
• The server holds authoritative data – no stale client‑side copies.
• Cros​s‑component sharing costs zero – just read from same cache tag.

• You must understand and trust Next.js’s caching mechanics.
• Eagerly changing data may need bypassing cache.
• If caching breaks。debugging can be non‑trivial.

跨组件同步方式 React Context + dispatch URL 参数 revalidateTag 自动触发

谁负责更新 Header 数字 订阅 context 的 Header 自动更新 CMS Shell 同一 cache tag 的所有组件统一重取

User Pain Point Highlighted: 多标签页/跨设备一致性 → 解法一需要自行实现同步机制 → 解法二依赖 CMS 实现，全局体验薄弱 → 解法三依赖服务器单一来源，一致性最佳

*以上对比仅供参考，实际选型需结合业务规模、团队组织还有实时性要求。

---