小程序开发接单：从框架选型到审核上架，我把踩过的坑都写出来了

[DevYuFeng]

先说清楚：这篇是来接小程序开发的活的，所以先把做小程序这几年踩的坑写出来，觉得有用再往下看。

做过的偏小程序 / App 类的项目：

• 体检预约小程序（ Taro + TypeScript ，个人端 + 企业端，从需求到上线 22 天）
• 跨平台电商 App （ UniApp ，一套代码出多端）
• 几个预约、报名类的轻业务小程序

小程序最容易踩的四个坑

1.框架选型别拍脑袋。 原生、Taro 、UniApp 三条路，看需求选：

• 只发微信一个端、交互不复杂 → 原生就够，包体小、审核顺、调试也直接
• 要同时出微信 + 支付宝 + 抖音，或团队是 React 栈 → Taro
• 要一套代码出 App + 小程序 + H5 → UniApp 见过太多项目一上来就上 Taro ，结果只发微信一个端，多了一层编译抽象，调试反而更折腾。

2.审核雷区比你想的多。 个人主体能做的类目很有限，社交、医疗、金融、电商很多要企业资质甚至特许资质； iOS 端虚拟支付基本走不通；名字里带别的品牌商标会被打回。立项前先把这些确认了，别等开发完被卡在审核——我接项目前会先帮你过一遍资质，过不了会直说，不接这种做完了上不了线的活。

3.登录授权流程，很多人写反。 正确顺序是 wx.login 拿 code → 后端用 code 换 openid / session_key → 后端下发自定义登录态。不要在前端拿 session_key ，也别把 openid 直接当用户唯一身份存——跨小程序矩阵唯一身份是 unionid 。这一步写错，后面合并账号、迁移数据会很痛。

4.多端差异比框架宣传的大。 就算用了 Taro / UniApp ，各端的组件、API 、审核规则、支付方式都不一样：微信 wx.*，支付宝 my.*，抖音支付又是另一套。"一套代码多端"省的是代码结构，不是适配工作量，报价的时候别信"零成本多端"。

我接什么

专接业务型小程序：预约、报名、会员、商城、内部工具、私域运营。不接纯展示页（那种找设计师更快）。

• 轻业务小程序（单端、3–5 个核心页面 + 简单后台）：1 万起
• 业务型小程序（多角色、表单链路、支付、排期）：2 万起
• 跨平台多端（微信 + 支付宝 + 抖音 / App + 小程序）：按端数评估

包含：选型建议、需求拆解、前端 + 后端 + 部署、审核辅助、交付文档和一次培训。免费维护 3 个月，之后按月或按次。

什么我不接

• 个人主体想做社交 / 医疗 / 电商类目的——资质过不了，别白花开发费
• 几千块做整套商城的
• 只画 UI 不碰逻辑的，这种找设计师更合适
• 要驻场的