从零到上线：一个小程序制作过程的完整记录

很多人问我：做一个微信小程序到底要经历哪些步骤？这篇文章不讲概念，只按我最近交付的一个预约类小程序，把从想法到上线的完整过程拆开写一遍。整个过程大约花了 3 周，其中真正写代码的时间不到一半，剩下的都花在确认需求、联调接口和提审上。

一、先别写代码，把「一句话需求」写清楚

我见过太多项目死在第一步：需求是一团模糊的愿望。我的做法是逼自己写出一句话：

用户可以在小程序里选择服务项目、选时间、下单支付，商家在后台看到预约并确认。

这句话里包含了角色（用户、商家）、核心动作（选、付、确认）和数据流向。写不出来，说明还没想清楚。接下来把它拆成页面清单：

• 首页：服务项目列表 + 搜索
• 详情页：项目介绍、价格、可选时段
• 下单页：填写联系人、备注、支付
• 订单列表：待确认 / 已完成 / 已取消
• 商家后台：用网页端做，不进小程序

这一步的产出是一张页面结构图，用纸笔或者任意画图工具都行，重点是让「页面数量」和「跳转关系」固定下来。后面所有工作量估算都基于它。

二、技术选型：能用原生就不用花哨的

这个项目不需要复杂动画，也不需要多端复用，我直接选了微信原生 + 云开发。理由很实在：

• 没有独立后端，云函数和云数据库省掉服务器运维；
• 支付、登录、订阅消息都是官方能力，接起来路径最短；
• 出问题时排查范围小，不用在框架和平台之间来回猜。

如果你的项目未来要同时上多端，再考虑跨端框架；如果只是单端小程序，原生开发在调试体验上仍然是最顺的。选型没有对错，只有「这个项目需不需要」。

三、搭骨架：先跑通一条主链路

我习惯先不写业务，而是把「登录 → 拿数据 → 提交 → 展示结果」这条链路用假数据跑通。云开发里初始化很简单：

// app.js
App({
  onLaunch() {
    if (!wx.cloud) {
      console.error('请使用 2.2.3 以上基础库');
      return;
    }
    wx.cloud.init({
      env: 'your-env-id',
      traceUser: true
    });
  }
});

页面里先用本地 mock 数组渲染列表，确认样式和交互没问题，再换成云数据库查询。这样做的好处是：样式问题、逻辑问题、数据问题不会同时爆发，排查成本低很多。

数据结构要先定，别边写边改

预约类小程序的核心集合其实就三个：服务项目、时段、订单。订单里我会额外存一份项目快照（名称、价格），因为项目价格以后可能调整，历史订单不能被改掉。这类「当时的数据」和「现在的数据」混在一起，是后期最常见的坑之一。

四、把交互细节磨一遍

骨架跑通后，真正影响体验的是细节。这个项目里我重点处理了四处：

• 加载状态：列表首次加载显示骨架屏，下拉刷新不闪白；
• 空状态：没有订单时给出引导按钮，而不是一片空白；
• 重复提交：下单按钮点击后立即置灰并加锁，防止网络慢时连点生成两笔订单；
• 错误提示：把云函数返回的错误码翻译成人话，比如「该时段已被预约，请换一个」。

这些点单看都不起眼，但用户投诉往往就集中在这些地方。写的时候多问一句「如果这里失败了，用户看到什么」，能省掉很多售后沟通。

五、联调支付与订阅消息

支付是流程里最容易卡住的一环。我的顺序是：先用云函数统一下单拿到支付参数，前端调起支付，支付成功后不依赖前端回调，而是在云函数里通过支付结果通知更新订单状态。前端只负责跳转到「支付结果页」并轮询一次订单状态。这样即使用户支付后立刻杀掉小程序，订单也不会丢。

订阅消息同理，授权要在用户点击「预约」这个明确动作时申请，不要在启动时弹，否则通过率会很难看。

六、提审前的自查清单

提交审核被拒一次，至少耽误一两天。我每次提审前会过一遍：

1. 所有页面在无数据、弱网下都能正常显示；
2. 隐私协议、用户信息收集说明已补齐；
3. 测试账号和操作路径写在审核备注里；
4. 去掉所有测试用的假数据和调试入口；
5. 类目选择和实际功能一致。

尤其是类目，选错是最常见的驳回原因，和代码质量无关。

七、上线不是终点

上线后我加了一个很轻的埋点：记录每个页面的进入次数和下单转化。第一周数据就暴露了一个问题——详情页到下单页的流失很高，原因是可选时段默认折叠，用户没意识到要点开。把时段直接平铺后，转化明显回升。

所以「小程序制作过程」真正完整的说法应该包含上线后的迭代。代码写完只是把产品交出去，接下来靠真实数据一点点修，才是这个活儿最有意思的部分。