郑州小程序开发实录：从需求到上线

上周把一位郑州客户的小程序送上线了，从第一次见面到审核通过，前后二十来天。这篇不聊大道理，就把过程摊开写一遍，给本地想做小程序的朋友一个参考，也当是自己的一次复盘。

一、需求不是聊出来的，是问出来的

客户在郑东新区做社区生鲜，门店不大，但周边三个小区的复购挺稳。他最初的想法很朴素：做个能下单的小程序就行。真坐下来聊，问题就冒出来了——要不要支持自提？配送范围怎么划？临期商品怎么打折？这些不提前定，后面全是返工。

我的习惯是拿一张纸画流程，边画边问：

• 用户从哪进来？扫码、分享还是搜一搜？
• 下单后谁接单？店员用手机还是电脑？
• 退款谁审核？有没有时限？

问完一圈，需求文档基本就有了雏形。这一步花两三个小时，能省后面好几天的扯皮。

二、技术选型：别为了新而新

这个项目我用了微信原生加云开发。原因很实际：客户没有服务器运维的人，云开发的数据库和云函数够用，成本也低。订单量在几百单一天的量级，没必要上太重的架构。

// 下单云函数的核心逻辑（简化版）
const cloud = require('wx-server-sdk')
cloud.init({ env: cloud.DYNAMIC_CURRENT_ENV })
const db = cloud.database()

exports.main = async (event) => {
  const { openid } = cloud.getWXContext()
  const { items, addressId, remark } = event
  if (!items || !items.length) {
    return { code: 400, msg: '购物车是空的' }
  }
  const total = items.reduce((s, i) => s + i.price * i.count, 0)
  const res = await db.collection('orders').add({
    data: {
      openid, items, addressId, remark,
      total, status: 'pending',
      createdAt: db.serverDate()
    }
  })
  return { code: 0, orderId: res._id }
}

云开发不是万能药，但它确实让一个人的团队能扛住一个完整项目。做郑州小程序开发这几年，我见过太多小项目一上来就堆微服务，最后维护成本把利润吃干净。

三、几个容易翻车的细节

1. 支付回调要幂等

微信支付的回调可能重复推送，订单状态更新一定要判断当前状态，别一收到回调就改。我一般会先查订单，状态已经是 paid 就直接返回成功。

2. 图片别直接传原图

生鲜商品图多，前端上传前压缩一下，云存储里也做尺寸限制。不然列表页加载慢，用户等两秒就走了。

3. 审核前把测试数据清干净

这个坑踩过一次，测试订单留在数据库里，审核员看到一堆“测试商品1”，直接打回。上线前清库、关调试开关，都是小事，但真能卡住进度。

四、本地客户的沟通节奏

郑州这边不少老板是实干型，不爱看文档，喜欢直接看东西。所以我的做法是每完成一个模块就发个体验版二维码，让他上手点一点。比开会讲半小时管用。这位客户第一次体验完就提了个很实在的需求：能不能在首页显示今天几点截单。这种细节，只有真实用起来才想得到。

另外，本地做小程序有个天然优势——见面方便。遇到支付配置、主体认证这类需要当面确认的事，约个咖啡就解决了，比远程来回发截图快得多。

五、上线之后才是开始

审核通过那天客户挺高兴，我跟他说别急着庆祝，先看三天数据。上线后我们盯了几个指标：首页到商品页的点击率、加购转化、下单完成率。发现加购到下单这一步流失偏高，查下来是配送时间选择太靠后，用户填完地址才看到“今日已截单”。把截单提示挪到商品页顶部，第二天转化就回来了。

小程序不是做完就完事的东西，它更像一个需要养的产品。知码客这边接的项目，上线后一般会留一段观察期，帮着看数据、调细节。毕竟代码改变生活这句话，落到实处就是让生意顺一点、让用户少点一次。

如果你也在郑州，正琢磨着做个小程序或者 APP，不妨先把业务流程捋清楚再来聊，能省不少时间。