三个小程序定制开发案例复盘

做小程序开发这些年，接过不少单子，有顺利交付的，也有差点翻车的。今天挑三个印象比较深的定制开发案例，把需求、坑和最后怎么解决的都写出来，给准备做小程序或者刚入行的朋友一点参考。案例里的客户信息都做了模糊处理，数据也做了调整，但技术上的东西是真实的。

案例一：社区团购小程序，卡在库存并发上

客户是本地一个做生鲜的团队，原来用微信群接龙，每天几百单，人工统计到半夜。需求很明确：商品列表、下单、自提点选择、团长分佣。听起来是个标准模板就能改的东西，报价也不高，但真正做起来问题出在库存上。

秒杀时段同一商品几十个人同时下单，云开发的数据库事务处理不好就会超卖。第一版我们用的是先查库存再减库存，压测的时候直接暴露问题。后来改成用数据库的原子操作，在更新时带上库存大于零的条件，再用云函数做一层排队，才算稳住。

// 云函数里扣库存，避免先查后减的竞态
const res = await db.collection('goods')
  .where({ _id: goodsId, stock: _.gt(0) })
  .update({ data: { stock: _.inc(-1) } })
if (res.stats.updated === 0) {
  throw new Error('库存不足')
}

这个案例给我的教训是：小程序定制开发里，凡是涉及库存、余额、名额的，别用“先读后写”的思路，一定要把判断条件放进更新语句里。另外自提点那块客户临时加了“按距离排序”，我们提前把经纬度存好了，加个云函数算距离就完事，没返工。

案例二：工厂设备巡检，离线场景是重点

这个客户是廊坊一家制造企业，车间信号差，巡检员拿着手机走到某些角落就没网。他们之前找过一家外包，做出来的东西一断网就白屏，工人意见很大。

我们接手后，核心改动是把数据先写本地缓存，联网后再同步。小程序这边用 wx.setStorageSync 存待上传的记录，页面加载时先读缓存渲染，网络恢复后触发批量提交。同步逻辑里加了唯一 ID，服务端做幂等，重复提交不会产生脏数据。

• 巡检项配置放服务端，小程序端只做展示和采集，方便后期改表单
• 照片压缩后再上传，车间里一次巡检十几张图，不压缩流量扛不住
• 提交失败给明确提示，别让工人以为存上了

上线后客户反馈不错，后来又加了设备报修和备件申领两个模块。这种 To B 的小程序开发，需求往往不是一次说完的，第一版把数据结构设计好，后面加功能才不痛苦。

案例三：预约类小程序，被审核卡了两次

第三个是个美容工作室的预约小程序，功能不复杂：选项目、选时间、付定金。开发本身两周就完了，结果微信审核卡了两次。第一次是因为类目选错，第二次是页面里有“充值”字样但没资质。

这里说个实在话：很多小程序定制开发项目延期，不是代码写不完，是审核和资质没提前确认。我的建议是动手前先去公众平台把类目、需要的资质查清楚，涉及支付、医疗、教育的尤其要小心。文案上避开敏感词，充值、返现、投资这类词能不用就不用。

给准备做小程序的朋友一句提醒：签合同前把“上线”和“审核通过”分开写，审核不过谁负责改、改几轮，白纸黑字写清楚，后面少扯皮。

几个通用的经验

三个案例下来，有些东西是共通的：

1. 需求文档不用多漂亮，但边界要清楚。哪些做、哪些不做，写下来双方签字，比口头约定强一百倍。
2. 能用云开发就别硬上服务器。中小项目用云开发，省运维省成本，上线快，后期量大了再迁也不迟。
3. 性能优化别等上线后。首屏加载、图片大小、列表分页，开发阶段顺手做了，比事后救火便宜。
4. 留好埋点。客户说“不知道用户为啥不用”，有数据才能回答。

小程序开发这行，技术门槛其实不算高，难的是把需求理解透、把边界划清楚、把坑提前想到。上面这些案例写出来，希望对正在做小程序定制开发或者准备找外包的朋友有点用。有问题欢迎留言交流。