分销商城小程序，我踩过的三个坑

去年接了个分销商城小程序的活，客户是做母婴用品的，想让自己几百个老客户帮忙带货。需求听起来不复杂：用户能申请成为分销员，分享商品链接，别人下单后按比例返佣金。我当时觉得两周能搞定，结果前后折腾了一个多月。今天把踩过的坑写出来，给准备做分销商城小程序的同行提个醒。

坑一：分销层级别想当然

客户一开始说“二级分销”，我以为就是 A 推荐 B、B 推荐 C，C 下单 A 和 B 都拿钱。真做起来才发现，问题在于关系绑定：用户没注册就点了分享链接，后来才登录，这个上下级关系怎么算？是点击就绑，还是下单才绑？

我最后定的规则是：首次点击分享链接时记录一个临时关系，用户完成注册后转为正式绑定，有效期 30 天。代码上就是分享链接带个参数，落地页存到本地和云端两头：

// 分享链接携带邀请人ID
const shareUrl = `/pages/goods/detail?id=${goodsId}&inviter=${userId}`;

// 落地页解析并缓存
onLoad(options) {
  if (options.inviter) {
    wx.setStorageSync('inviter_id', options.inviter);
  }
}

// 注册成功后绑定关系（云函数里做校验，防止重复绑定）
await db.collection('user_relation').add({
  data: {
    userId: newUserId,
    inviterId: inviterId,
    bindTime: db.serverDate(),
    status: 1
  }
});

这里提醒一句，微信对分销是有红线的，层级超过三级、靠拉人头收费的模式容易被封。做分销商城小程序之前，先把规则想清楚，别等上线了被投诉下架。

坑二：佣金结算的并发问题

订单支付成功要触发佣金计算，我最初写在支付回调里直接算。测试时没问题，一上量就出事了：同一个订单回调触发了两次，佣金发了两遍。客户对账时发现账对不上，差点以为我在里面做手脚。

后来改成幂等处理，用订单号做唯一键，云函数里先查再写：

// 云函数：结算佣金
exports.main = async (event) => {
  const { orderId } = event;
  const exist = await db.collection('commission_log')
    .where({ orderId }).count();
  if (exist.total > 0) {
    return { code: 0, msg: '已结算' };
  }
  // 计算并写入佣金记录
  // ...
};

另外佣金别实时到账，设个冻结期，比如确认收货 7 天后才可提现。这样退款、售后都有缓冲，不然用户一退款，佣金已经提走了，你就得自己垫钱。

坑三：提现功能别自己硬扛

分销商城小程序绕不开提现。我一开始想用微信商户号的“企业付款到零钱”，结果发现需要单独申请，还有资质和流水要求。折腾了几天，最后跟客户商量改成人工审核 + 线下转账，小程序里只做提现申请和记录展示。

说实话，对中小商家来说这个方案更实际。提现申请列表、审核状态、打款备注这些做好，体验并不差，还省了对接成本。等单量真上来了再考虑接支付通道也不迟。

几点实在的建议

• 分销商城小程序的核心不是技术，是规则设计。层级、绑定、结算周期，先跟客户白纸黑字定下来。
• 佣金计算全部放服务端，前端只做展示，别信客户端传上来的金额。
• 数据表设计时把“关系表”和“佣金流水表”分开，后面查账、对账会轻松很多。
• 上线前用测试账号把“分享—注册—下单—结算—提现”整条链路走三遍，尤其是重复回调这种边界情况。

分销商城小程序这个需求，市面上模板不少，但真能跑顺的不多，问题基本都出在结算和关系绑定这些细节上。自己动手做的话，多花点时间在规则和异常处理上，比堆功能有用得多。