商城小程序开发，我踩过的三个坑

去年接了个商城小程序开发的活，客户是做本地生鲜的，一开始我觉得这单挺简单——商品列表、购物车、下单支付，模板一套不就完了。结果真做起来才发现，商城类项目的水比想象中深。今天不聊虚的，就说三个我自己踩过的坑，给准备做商城小程序的同行提个醒。

坑一：别急着写页面，先把订单状态机想清楚

我第一版直接照着模板改，商品详情页两天搞定，自我感觉良好。等到做订单模块的时候傻眼了：待付款、待发货、待收货、已完成、已取消、退款中……每个状态能做什么操作、超时怎么处理、库存什么时候扣、什么时候回滚，全是连锁反应。

后来我干脆停下来，拿张纸把状态流转画了一遍，才动手写代码。核心逻辑大概是这样：

const ORDER_STATUS = {
  UNPAID: 0,      // 待付款
  PAID: 1,        // 已付款待发货
  SHIPPED: 2,     // 已发货
  FINISHED: 3,    // 已完成
  CANCELLED: 4,   // 已取消
  REFUNDING: 5    // 退款中
}

// 下单时先锁库存，支付超时再释放
async function createOrder(goodsId, count) {
  const locked = await lockStock(goodsId, count)
  if (!locked) throw new Error('库存不足')
  const order = await db.collection('orders').add({
    data: { goodsId, count, status: ORDER_STATUS.UNPAID, createdAt: Date.now() }
  })
  // 30分钟未支付自动取消
  scheduleCancel(order._id, 30 * 60 * 1000)
  return order
}

这一步花了我大半天，但后面少返工至少三天。真心建议：商城小程序开发，订单和库存是命门，先设计再编码。

坑二：支付回调不能只信前端

新手最容易犯的错——前端调起支付成功后就直接把订单改成已付款。我早期也这么干过，测试环境没问题，上线后被人用工具伪造请求，白嫖了两单。虽然金额不大，但脸疼。

正确做法是：前端支付成功只负责跳转提示，订单状态必须以微信支付的服务端回调为准。回调里要做签名校验，还要做幂等处理，因为微信可能重复通知。

// 云函数里处理支付回调
exports.main = async (event) => {
  const { out_trade_no, result_code } = event
  if (result_code !== 'SUCCESS') return { errcode: 0 }
  // 幂等：已处理过就直接返回
  const order = await db.collection('orders').doc(out_trade_no).get()
  if (order.data.status !== ORDER_STATUS.UNPAID) return { errcode: 0 }
  await db.collection('orders').doc(out_trade_no).update({
    data: { status: ORDER_STATUS.PAID, paidAt: Date.now() }
  })
  return { errcode: 0 }
}

坑三：首页别堆功能，性能会教你做人

客户一开始要求首页放轮播、分类、秒杀、推荐、公告、优惠券……我照做了，结果低端安卓机上首屏加载四五秒，白屏明显。后来做了减法：

• 轮播和分类用云开发数据库一次请求拿完，别拆成多个接口；
• 商品图片全部走 CDN 并压缩，列表用懒加载；
• 秒杀模块单独拆页，首页只留入口；
• 骨架屏先顶上，别让用户盯着白屏。

改完之后首屏基本两秒内出来，客户那边反馈也好了不少。商城小程序开发不是功能越多越好，用户点进来三秒看不到东西就走了，后面做得再花哨也白搭。

最后说两句

这个项目做完，我最大的感受是：商城小程序开发看起来是模板活，实际上考验的是对业务细节的把控。库存、支付、性能这三块稳住了，剩下的界面反而好办。如果你也是独立开发者接这类单子，报价的时候记得把订单状态机和回调联调的时间算进去，别像我第一次那样按页面数量估工时，最后自己贴时间。

后面有空再写写云开发数据库索引和分页那块，也是踩过坑的地方。