北京小程序开发实录：从需求到上线

上周把朝阳区一个客户的小程序交付上线了。从第一次见面聊需求，到正式发布，前后差不多六周。中间踩了几个坑，也攒了些经验，趁记忆还热乎，记下来。

需求阶段：别急着写代码

客户在海淀做社区生鲜，想做一个下单+自提的小程序。第一次沟通时，对方列了二十多条功能，从会员积分到拼团到直播带货全都有。我没急着报价，先问了一句：现在店里每天多少单？答：三十多单，主要靠微信群接龙。

这就好办了。三十单的量，上拼团和直播纯属浪费预算。最后砍到核心三块：商品展示、下单支付、到店自提核销。功能少了，开发周期短了，客户的钱也花在刀刃上。

在北京做小程序，这类情况特别常见。很多客户被各种“全功能方案”忽悠过，一上来就要大而全。我的习惯是先看业务量，再看功能清单。功能是长出来的，不是堆出来的。

技术选型：够用就行

这个项目用了微信原生框架加云开发。没上 uni-app，因为客户明确只做微信端，多端框架反而增加调试成本。云开发省掉了服务器和域名备案的麻烦，对中小项目很友好。

// 自提核销的核心逻辑，简化版
async function verifyPickup(orderId, staffId) {
  const order = await db.collection('orders').doc(orderId).get()
  if (order.data.status !== 'paid') {
    return { ok: false, msg: '订单状态异常' }
  }
  await db.collection('orders').doc(orderId).update({
    data: { status: 'picked', pickedAt: Date.now(), staffId }
  })
  return { ok: true }
}

云开发的数据库权限要特别注意，默认权限别图省事设成“所有用户可读写”。这个项目里订单表只允许创建者读，核销操作走云函数，绕开客户端直接改库的风险。

开发中遇到的三个坑

1. 支付回调的幂等

微信支付的回调可能重复推送。第一版没做幂等，测试时手动触发两次回调，订单状态被改了两遍，库存也扣重了。后来在云函数里加了状态判断，只有待支付状态才处理，问题解决。

2. 图片加载慢

客户传的商品图都是手机直出，一张三四兆。列表页一加载，白屏好几秒。做了两件事：上传时用云存储的图片处理能力压缩，列表用缩略图，详情页才加载原图。改完之后首屏快了不少。

3. 自提点的距离排序

客户有三个自提点，希望按用户位置排序。用了 wx.getLocation 拿经纬度，再算直线距离。注意要在 app.json 里声明地理位置权限，并且首次调用要引导用户授权，不然直接失败。

上线前的检查清单

• 隐私协议和用户信息收集说明是否齐全，现在审核卡得严
• 类目选择是否匹配，生鲜电商要选对经营类目
• 测试号跑一遍完整下单流程，包括退款
• 体验版发给客户，让店里员工实际用两天再提审

提审一次过。客户反馈说店员上手很快，核销扫个码就行，比之前翻微信群记录强多了。

一点感受

做北京小程序开发这几年，接触的客户从胡同里的小店到写字楼里的创业团队都有。技术方案没有高低之分，关键是贴着业务走。知码客这个名字里的“知码识途”，说的就是这个意思——代码是工具，路得看清楚再走。

这个项目不大，但每个环节都踏实走完了。下一篇文章打算聊聊老客户复购时怎么在原有小程序上做迭代，有兴趣的可以关注。