我做小程序开发五年，说几句大实话

后台经常有人问我：现在做小程序开发还来得及吗？每次看到这种问题我都想笑，因为五年前我刚接第一个私活的时候，也这么问过自己。今天不聊虚的，说说这几年踩过的坑和攒下的经验，想到哪写到哪。

先说说我是怎么入坑的

最开始我是做 Web 前端的，2018 年有个开水果店的朋友找我，说想弄个能下单的小程序。那时候我连微信开发者工具都没装过，硬着头皮看了三天文档就上手了。做完那个水果店的项目，我发现这东西比想象中简单，但要做好又比想象中难。简单是因为语法跟写网页差不多，难的是各种审核规则、支付流程、还有那些文档里没写清楚的坑。

后来就慢慢接活，从水果店做到连锁餐饮，从零散客户做到有固定合作方。这几年下来，我对小程序开发这件事的理解变了好几轮。

技术选型：别一上来就追求高大上

新手最容易犯的错，就是觉得原生开发不够酷，非要上 uni-app 或者 Taro。我理解这种心态，但说句实话：

• 如果你的项目只跑微信端，老老实实用原生，调试方便，遇到问题搜到的答案也多；
• 只有当你明确要同时出 H5、App、多端小程序的时候，跨端框架才划算；
• 云开发适合小项目快速验证，但业务一复杂，数据库查询和权限管理会让你抓狂。

我有个客户，一开始非要我用某跨端框架，结果上线后安卓机上白屏，查了两天才发现是框架版本和基础库不兼容。后来重写成原生，两天搞定。所以选型这事，别听网上吹，看你的实际需求。

那些文档里不会告诉你的坑

1. 审核不是走过场

第一次提交审核被拒的时候，我盯着那条“功能不完整”的提示看了半小时。后来才明白，审核员看到的是你提交的版本，不是你本地跑通的版本。所以提交前一定要用体验版完整走一遍流程，尤其是涉及登录、支付、定位这些敏感能力的地方。

2. 支付回调要幂等

这个坑我踩过两次。微信支付的回调可能会重复推送，如果你的订单状态更新没做幂等处理，用户付一次钱，你给人家发了两次货。处理方式很简单，回调里先查订单状态，已处理就直接返回成功。

// 伪代码，核心是判断状态
async function handlePayNotify(orderId) {
  const order = await getOrder(orderId);
  if (order.status === 'paid') {
    return { code: 'SUCCESS' };
  }
  await updateOrderStatus(orderId, 'paid');
  return { code: 'SUCCESS' };
}

3. 包体积控制

主包 2M 的限制卡死过不少人。图片别往包里塞，全放 CDN；不常用的页面做成分包；第三方 SDK 能不用就不用，非要用的挑轻量的。我见过一个项目，光一个富文本编辑器就占了 800K，最后只能砍功能。

关于报价和外包这件事

经常有人拿个需求文档来问我多少钱，我一般先问三个问题：有没有设计稿？要不要对接支付？后期谁维护？

小程序开发的报价差异特别大，同样一个商城，有人报三千有人报三万。差别不在代码量，在于需求边界清不清楚。需求越模糊，后期扯皮越多，价格自然越高。我建议找外包的老板，合同里一定写清楚功能清单和验收标准，别信“先做出来看看”这种话。

另外，别把小程序当成一次性买卖。上线只是开始，后面还有版本迭代、微信规则变化、服务器续费。预算里留出维护的钱，不然出了问题找不到人，更麻烦。

给想入行的朋友几句话

小程序开发这个方向，门槛确实不高，但天花板也不低。如果你只是想接点小活赚外快，学个把月就能上手；但想靠这个吃饭，得把支付、登录、订阅消息、地图这些常用能力吃透，还得懂点后端和运维。

我现在接活越来越挑，不是因为架子大，是因为知道哪些项目能做、哪些做不了。技术这东西，承认自己不会，比硬着头皮上要体面得多。

就写这么多吧，有问题评论区聊。