小程序开发踩坑三年，我总结了这5条

做小程序开发快三年了，从最早接外包帮人做商城，到后来自己维护几个小工具，踩过的坑能写一本书。今天不聊虚的，就说几个我真实遇到过、并且觉得对新手最有用的点。如果你正准备入行或者刚接第一个项目，希望能帮你少走点弯路。

一、别一上来就追求“架构优雅”

我第一个小程序项目，客户要一个预约功能。我当时刚看完几篇讲分层架构的文章，兴致勃勃地搞了 service 层、utils 层、store 层，一个页面拆了六个文件。结果呢？需求改了三版，每次改都要在四个文件之间跳来跳去，最后自己都绕晕了。

小程序的体量决定了大部分项目根本不需要那么重的架构。页面逻辑超过 300 行再考虑抽离，公共方法出现第三次再封装。过早抽象是给自己挖坑，尤其是需求还没稳定的时候。

// 早期我会这么写
// utils/request.js
// services/order.js
// store/order.js
// pages/order/index.js

// 现在一个预约页就一个文件，直接调 wx.request
Page({
  data: { list: [] },
  onLoad() {
    this.fetchList()
  },
  fetchList() {
    wx.request({
      url: 'https://api.example.com/orders',
      success: (res) => this.setData({ list: res.data })
    })
  }
})

二、setData 的性能问题，真不是玄学

很多人说小程序卡，其实一大半是 setData 用错了。我见过一个列表页，每次滚动都 setData 整个数组，几百条数据来回传，不卡才怪。

几个实测有效的做法：

• 只传变化的那一项，用 this.setData({ ['list[' + index + '].status']: 1 }) 这种路径写法；
• 列表超过 50 条就考虑分页或者虚拟列表，别一次性全渲染；
• 频繁触发的场景（比如滚动、输入）加节流，别每次事件都 setData。

我有个工具类小程序，优化前首屏渲染要 1.2 秒，把大数组的 setData 改成增量更新后，直接降到 400 毫秒左右。用户感知非常明显。

三、云开发适合谁，不适合谁

云开发刚出来那会儿我很兴奋，觉得后端都省了。用下来结论是：适合轻量工具、个人项目、快速验证，但不适合有复杂业务逻辑或者高并发的场景。

它的好处很明显，数据库、云函数、存储一把梭，不用买服务器不用备案，个人开发者做个小工具两三天就能上线。但限制也摆在那：云函数冷启动、数据库查询能力弱、复杂聚合操作写起来很别扭。我有个项目后来因为要做多表关联统计，硬是在云函数里写了一堆循环，最后还是迁回了自建后端。

所以选型的时候想清楚：你的数据关系复杂吗？有没有定时任务和大量计算？如果答案都是“没有”，云开发真香。

四、审核和上线，细节决定成败

这块是最容易翻车的。我整理几个被拒过的真实原因：

• 类目选错，功能跟类目对不上，直接打回；
• 页面里有“测试”“demo”字样，审核认为功能不完整；
• 收集用户手机号但没有隐私协议弹窗；
• 诱导分享，比如“分享给三个好友解锁”。

建议提审前自己走一遍完整流程，把每个按钮都点一遍，尤其是空数据状态和网络异常状态。审核员看到白屏或者报错，基本就是拒。

五、给自己留个“复用库”

这是我最近一年才养成的习惯。每次项目里写的登录逻辑、请求封装、常用组件，我都会整理到一个自己的模板仓库里。下一个项目直接拷过来改，省下的时间非常可观。

独立开发者最大的成本就是时间，能复用的绝不重写。哪怕只是一个通用的 loading 组件、一个日期格式化函数，攒着攒着就是一套自己的工具箱。

说到底，小程序开发门槛不高，但要做好，靠的是一个个项目磨出来的经验。别怕踩坑，踩完记下来，下次就是你的优势。