从想法到上线：我的小程序制作流程复盘

去年冬天，我用三个周末做了一款记账小程序。上线第一周只有 40 个用户，但整个过程踩的坑比预想多得多。这篇文章不讲空话，把我从想法到审核通过的完整流程复盘一遍，给准备动手的朋友一个参照。

一、动手前先想清楚三件事

很多人一上来就打开开发者工具建项目，结果做到一半发现方向不对。我现在的习惯是先花半天时间回答三个问题：

• 解决谁的什么问题：一句话说不清楚，就别做。
• 核心功能能不能砍到三个以内：第一版功能越少，上线越快。
• 有没有现成的替代品：有的话，想清楚你的差异点在哪。

这一步不需要写文档，拿张纸画几个方框就够了。我那个记账小程序最初想做预算、报表、多账本，最后只留了「快速记一笔」和「本月汇总」，反而更受欢迎。

二、注册与账号准备

流程本身不复杂，但有几个细节容易卡住：

1. 去微信公众平台注册小程序账号，个人主体也能注册，但部分类目（如涉及支付、医疗）需要企业资质。
2. 拿到 AppID 后，在开发者工具里绑定，否则无法真机预览。
3. 提前想好小程序名称，名称一旦通过审核修改成本较高，建议先查重。
4. 服务类目要选准确，选错了审核阶段会被打回，来回就是好几天。

提醒一句：个人主体的小程序不能开通微信支付，如果你的产品依赖收费，注册前就要考虑清楚主体类型。

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

我的建议很朴素：能原生就原生，团队小、需求简单时，原生开发调试链路最短。需要跨端时再考虑 uni-app 或 Taro。

项目结构我一般这样组织：

miniprogram/
  pages/          # 页面
  components/     # 自定义组件
  utils/          # 工具函数
  services/       # 接口请求封装
  app.js
  app.json

接口请求统一封装一层，方便加 loading、错误提示和 token：

const request = (url, options = {}) => {
  return new Promise((resolve, reject) => {
    wx.request({
      url: BASE_URL + url,
      method: options.method || 'GET',
      data: options.data || {},
      header: { Authorization: getToken() },
      success: (res) => {
        if (res.statusCode === 200) resolve(res.data);
        else reject(res);
      },
      fail: reject
    });
  });
};

四、开发阶段的几个实用习惯

• 先跑通主链路：从首页到核心操作再到结果页，先让流程能走通，样式后调。
• 用真机调试：模拟器和真机差异不小，尤其是键盘弹起、滚动穿透这类问题。
• 数据先本地后云端：早期用本地缓存验证交互，逻辑稳定后再接云开发或自建后端。
• 控制包体积：主包别超过 2MB，图片放 CDN，能压缩就压缩。

云开发对独立开发者很友好，省去服务器和备案，适合快速验证。但要注意它的免费额度和数据导出限制，用户量上来后要评估迁移成本。

五、提审前自检清单

审核被打回是常态，提前自检能省不少时间：

• 所有页面在无数据时是否有空状态提示；
• 是否存在未完成的按钮或「敬请期待」文案；
• 用户信息、位置等权限是否在使用时才申请，并说明用途；
• 隐私政策是否配置，涉及收集信息的功能必须声明；
• 测试账号是否在提审备注里写清楚。

我第一次提审就是因为一个「分享」按钮点了没反应被拒，补上逻辑后第二天就过了。

六、上线不是终点

审核通过后，建议立刻做三件事：接入基础的数据统计，观察用户在哪一步流失；准备一个反馈入口，早期用户的抱怨就是最好的需求池；把版本迭代节奏定下来，小步快跑比憋大招靠谱。

回头看，小程序制作流程真正的难点不在写代码，而在每个环节的取舍。想清楚再动手，比写得多更重要。