电商App开发的骨架与细节

电商App看起来是「商品列表 + 购物车 + 下单」三件事，真正做起来却是一条从商品模型到支付回调、再到售后状态的完整链路。本文按一个可上线的电商App结构，拆解几个决定后期维护成本的关键设计点。

一、先把商品模型定死，再谈页面

很多电商项目后期改不动，根源在商品模型。SKU、SPU、规格、库存、价格这几者的关系必须在写第一行界面代码前确定。

• SPU：描述「这是什么商品」，承载标题、主图、详情、类目。
• SKU：描述「具体买哪一件」，承载规格组合、独立价格、独立库存。
• 规格：颜色、尺寸等维度，用有序数组存储，SKU 通过规格值索引关联。

建议 SKU 用「规格值 ID 排序后拼接」作为唯一键，例如 red_128g，这样前端选规格时可以直接拼 key 查库存，不必遍历数组。

{
  "spuId": "10086",
  "title": "无线蓝牙耳机",
  "skus": [
    { "skuId": "red_128g", "price": 29900, "stock": 12, "specs": ["red", "128g"] },
    { "skuId": "black_128g", "price": 29900, "stock": 0, "specs": ["black", "128g"] }
  ]
}

价格统一用「分」为单位的整数存储，避免浮点误差。这个决定在结算、优惠券、退款分摊时能省掉大量对账问题。

二、购物车与结算的状态归属

购物车分两种：本地购物车和登录后购物车。常见做法是未登录时存本地，登录后合并到服务端。合并逻辑要明确规则：同一 SKU 数量相加还是取较大值，下架商品如何处理，都要写进接口文档。

结算页不要直接读购物车，而应由服务端根据「选中的 SKU + 优惠 + 地址」生成一份订单预览，返回应付金额和可用优惠。用户点击提交时，用预览返回的 token 或快照下单，防止前端篡改价格，也避免用户在结算页停留期间价格变动导致金额不一致。

三、订单状态机是电商的骨架

订单不要用一堆布尔字段（isPaid、isShipped、isClosed）表达，而要用单一状态字段加状态机。一个够用的最小集合：

• 待支付 → 已支付 → 待发货 → 已发货 → 已完成
• 待支付 → 已取消（超时或主动取消）
• 已支付 → 退款中 → 已退款

每次状态流转都写一条流水记录，包含来源（用户、系统、支付回调）和时间。售后、对账、客服排查全靠这张流水表。状态机用服务端统一校验，禁止前端直接改状态。

四、支付回调必须幂等

支付平台的回调可能重复到达，也可能先于前端跳转到达。处理原则：

1. 以支付平台订单号为唯一键落库，重复回调直接返回成功。
2. 回调里只做「标记已支付 + 写流水 + 发消息」，不做耗时业务。
3. 发货、积分、优惠券核销等动作由消息队列异步消费，消费端同样幂等。

async function handlePayNotify(notify) {
  const exist = await db.payLog.findOne({ tradeNo: notify.tradeNo });
  if (exist) return { code: 'SUCCESS' };
  await db.transaction(async (t) => {
    await t.payLog.insert({ tradeNo: notify.tradeNo, raw: notify });
    await t.order.updateStatus(notify.outTradeNo, 'PAID');
    await t.orderFlow.insert({ orderId: notify.outTradeNo, from: 'UNPAID', to: 'PAID' });
  });
  await mq.send('order.paid', { orderId: notify.outTradeNo });
  return { code: 'SUCCESS' };
}

五、图片与列表的性能底线

电商App的流量大头是图片。几条低成本但收益明显的做法：

• 服务端按场景输出多尺寸图，列表用缩略图，详情用原图，禁止一张大图全场景复用。
• 列表使用固定高度占位，避免图片加载导致布局跳动。
• 分页接口返回游标而非页码，减少深翻页的数据库压力。
• 首屏只请求必要字段，详情描述等重内容延后加载。

六、成本与节奏的现实判断

一个能跑通交易闭环的电商App，最小版本通常包含商品、购物车、订单、支付、地址、售后入口六块。若团队只有一到两人，建议先做单端（小程序或App二选一），把订单状态机和支付链路打磨稳定，再扩第二端。两端共用同一套服务端接口，前端只做展示层差异，这样后续增加端时边际成本很低。

电商App的难点不在页面多，而在状态多、边界多。把商品模型、订单状态机、支付幂等这三件事做扎实，后面的营销玩法才有地方挂。