小程序开发避坑实战指南

为什么你的小程序上线后没人用

做了五年独立开发，接过不少小程序外包，也自己上线过几个产品。见过太多团队把小程序当 H5 写，上线后首屏三秒白屏、支付回调丢单、审核被拒三次。这篇文章不讲概念，只讲我踩过的坑和对应的解法，适合正在做或准备做小程序的朋友。

一、架构选型：别一上来就云开发

云开发确实省事，免服务器、免运维、自带数据库和存储，对个人开发者和小团队非常友好。但它不是银弹，我见过两个典型翻车场景：

• 复杂查询性能差：云数据库的聚合查询在数据量超过十万级后明显变慢，做报表类需求会很痛苦。
• 被绑定太深：业务做大后想迁到自建后端，数据导出和接口重写成本很高。

我的建议是：MVP 阶段用云开发快速验证，但把数据访问层抽一层薄封装，业务代码只调自己的 api.js，将来换后端只改这一层。下面是一个简单的封装示例：

// api.js
const call = async (name, data) => {
  const res = await wx.cloud.callFunction({ name, data });
  if (res.result.code !== 0) throw new Error(res.result.msg);
  return res.result.data;
};

export const getOrderList = (page) => call('getOrderList', { page });

这样业务层永远不直接碰 wx.cloud，迁移时心里不慌。

二、首屏性能：三个立竿见影的优化

小程序包体积上限是主包 2MB、总包 20MB，但用户感知的从来不是包大小，而是首屏可交互时间。按优先级做这三件事：

1. 分包加载 + 分包预下载

把非首页的页面全部拆到分包，主包只留 tabBar 页面和公共组件。再在 app.json 里配置 preloadRule，用户停留在首页时就静默下载常用分包：

{
  "preloadRule": {
    "pages/index/index": {
      "network": "all",
      "packages": ["shop"]
    }
  }
}

2. 图片走 CDN 并压缩

本地图片是包体积杀手。所有商品图、banner 图放 CDN，用 webp 格式，配合 image 组件的 lazy-load。一张 200KB 的图压到 30KB，首屏能快几百毫秒。

3. 骨架屏代替 loading

接口没回来之前别让用户看白屏。用静态骨架屏占位，数据到了再替换，体感上快很多。这比任何代码优化都划算。

三、支付与回调：最容易丢单的地方

微信支付的回调是异步的，而且可能重复推送。我见过最典型的 bug 是：前端 wx.requestPayment 成功后直接改订单状态，结果用户网络断了，钱扣了单没改。

正确姿势是以服务端回调为准：

• 前端支付成功后只做跳转和提示，不写业务状态。
• 服务端收到支付回调后，用订单号做幂等校验，再改状态。
• 前端跳转结果页时轮询订单状态，最多轮询 5 次，避免死等。

// 服务端回调伪代码
async function onPayNotify(orderNo, transactionId) {
  const order = await db.order.findByNo(orderNo);
  if (order.status === 'paid') return 'SUCCESS'; // 幂等
  await db.order.update(orderNo, { status: 'paid', transactionId });
  return 'SUCCESS';
}

四、审核被拒的常见原因

小程序上线审核比 App Store 宽松，但也有硬门槛，我总结了几条高频拒审点：

• 类目不符：卖食品必须有食品经营许可证，做医疗咨询需要资质，别想着选个「工具」类目蒙混。
• 诱导分享：文案里出现「分享给好友解锁」「转发抽奖」基本必拒。
• 虚拟支付：iOS 端小程序不能出现虚拟商品购买入口，会员、课程、金币都算。
• 测试账号：需要登录的功能，提交审核时务必在备注里提供可用的测试账号。

被拒不可怕，可怕的是不知道为什么被拒。每次提交前对照官方运营规范过一遍，能省掉大量返工。

五、给独立开发者的几句实话

小程序开发的门槛确实低，但做好一个能赚钱的小程序，难点不在写代码，而在需求判断和运营。我见过太多人花两个月做完一个「功能齐全」的小程序，上线后发现根本没人用。

先做能被验证的最小闭环，再谈体验优化。上线一周没有自然增长，就该反思需求而不是改代码。

技术层面，把上面这些坑避开，你的小程序已经能跑赢大部分同行。剩下的，交给产品和运营。