小程序定制开发：那些踩过的坑

做小程序定制开发这些年，我踩过的坑几乎能写一本小册子。这篇文章不吹不黑，只讲真实项目里让我返工、赔钱、掉头发的那些教训，希望能帮到准备做定制开发或者正在踩坑路上的朋友。

一、需求阶段：没写清楚就等于没做

最常见的坑，是需求文档写得像散文。客户说“要一个会员系统”，我理解成积分等级，客户想要的是付费订阅。这类歧义在开发后期会变成灾难。

• 把“用户中心”拆成具体页面：资料编辑、订单列表、优惠券、设置，一项项确认。
• 每个页面标注数据来源：是接口返回，还是本地缓存，还是需要后台配置。
• 对“管理后台”单独出原型，不要默认客户只需要小程序端。

我的做法是：需求确认后，让客户在原型上逐页签字（哪怕是微信里回一句“确认”），后续增改一律走变更单。没有这一步，后期扯皮时你没有任何依据。

二、报价阶段：漏算的永远是隐性成本

新手报价容易只算“写代码的时间”，但定制项目的成本大头往往在代码之外：

• UI 设计：客户反复改稿，三版起步是常态，报价时要写清“含几次修改”。
• 接口联调：客户提供的第三方系统接口文档不全，联调时间可能超过开发时间。
• 服务器与云资源：云开发虽然省事，但数据库读写次数和云函数调用量超限后会额外计费。
• 上线后的维护：微信审核被拒、基础库升级导致兼容问题，这些都要预留维护期。

我现在的报价单会把“设计修改次数”“联调对接方数量”“免费维护期”单独列项，超出部分按次收费。丑话说在前面，反而更容易成交。

三、技术选型：别为了炫技给自己挖坑

定制项目最怕过度设计。我见过用复杂状态管理库写一个只有五个页面的商城，结果新人接手看不懂，维护成本翻倍。中小型定制项目，我的原则是：

• 能用原生框架就用原生，减少构建链路和依赖体积。
• 需要后端但客户没有运维能力时，优先考虑云开发，省掉服务器部署和备案沟通。
• 支付、登录、订阅消息这类能力，严格按官方文档接入，别用来源不明的第三方封装。

// 订阅消息授权要在用户点击事件里同步调用，否则会失败
wx.requestSubscribeMessage({
  tmplIds: ['模板ID'],
  success(res) {
    if (res['模板ID'] === 'accept') {
      // 记录用户已授权，后续由服务端下发
    }
  },
  fail(err) {
    console.error('订阅授权失败', err);
  }
});

这类细节文档里都有，但很多人是在真机上测试失败后才回头翻文档，白白浪费半天。

四、上线阶段：审核规则比代码更难缠

代码写完不等于项目结束。微信审核的坑集中在几类：

• 类目选择错误：选了“工具”类目却提供交易功能，直接被拒。
• 诱导分享、诱导关注：文案里出现“分享得积分”很容易触发驳回。
• 隐私协议缺失：涉及收集用户信息却没有隐私保护指引，审核不通过。
• 测试账号问题：需要登录才能体验的功能，必须在提审时提供可用的测试账号。

经验之谈：首次提审前，把《微信小程序平台运营规范》里与自身业务相关的章节过一遍，比被拒三次再改要快得多。

五、交付阶段：源码和文档才是护城河

定制开发最容易留下后患的环节是交付。客户拿不到源码、没有部署文档、第三方账号还绑在开发者个人名下，后面换人维护就是一场灾难。我的交付清单固定包含：

1. 完整源码与依赖说明，附可运行的构建命令。
2. 数据库表结构与初始化脚本。
3. 小程序后台、云开发环境、支付商户号的管理员移交记录。
4. 一份简明的运维手册：如何发版、如何看日志、常见报错怎么处理。

把这些做完，项目才算真正结束。很多纠纷不是因为技术不行，而是因为交付边界模糊。

写在最后

小程序定制开发的坑，本质上大多不是技术坑，而是沟通坑和边界坑。需求写细、报价列全、选型克制、交付完整，这四件事做到位，能避开八成以上的麻烦。剩下的两成，就当作独立开发者的学费吧。