这两年问我“小程序怎么做”的人特别多有传统行业想开线上商城的老总有刚拿了融资想快速验证模式的创业团队也有做智能硬件想配套一个控制端的硬件工程师。大家的问题表面上是“开发一个小程序多少钱”“找哪家公司”但聊深了就会发现真正卡住的不是钱也不是技术而是不知道在哪个岔路口该做什么决策。小程序开发从来不是“写代码”一件事它是一条完整的链路业务定位、技术选型、功能取舍、合规备案、上线运营。每一步都有岔路选错了后面全是坑。这篇文章我打算把这条路径掰开揉碎用我做过的项目和踩过的坑讲清楚每个关键决策点背后的逻辑以及实操中可以直接照搬的经验。不管你是项目负责人、产品经理还是想自己动手做的开发者这篇内容都值得你花十分钟认真看完。1. 动工之前先把“做小程序”拆成几个决策点1.1 你做的到底是一个“渠道”还是一个“产品”这是第一个要回答的问题。很多老板一上来就说“我要做个小程序商城”但“商城”只是一个形式本质你要想清楚小程序在你的业务里扮演什么角色如果你是一个线下门店小程序就是你的线上货架和收银台核心任务是让老客复购、让人帮你转发裂变这时候小程序是渠道功能不用多支付、会员、优惠券、订单管理这几样做好就够用了。如果你是一个工具型产品比如之前我接触的一个血氧仪硬件团队他们的小程序是设备的控制面板和数据展示端用户扫码绑定设备查看历史数据这时候小程序就不是渠道而是产品本体体验和稳定性远比营销功能重要。还有一种情况你是做内容或服务的小程序相当于你的服务入口比如预约、报名、查询。我在实际需求调研中经常遇到客户把这三个角色混在一起什么都想做结果项目周期翻倍、预算超支。建议你在写需求之前先拿一张纸回答三个问题用户通过小程序完成的核心任务是什么这个任务多久发生一次如果小程序挂了对业务影响有多大答案越清晰后面所有决策越简单。1.2 目标用户与场景决定功能边界功能清单不是越多越好而是越匹配越好。我习惯用一个“三步法”来定功能边界列出用户在你业务链路中的所有触点比如看到广告、到店、购买、售后、分享。标出哪些触点必须由小程序承载哪些用公众号、企业微信甚至短信也能完成。把剩下的功能按“必须有”“可以有”“先不做”分成三档只开发“必须有”。举个例子我之前帮一个苗木交易客户规划小程序他一开始想要的是一套完整的B2B交易系统包括线上询价、合同签署、物流跟踪。但聊完场景后发现他们的大客户都是通过电话和微信成交的小程序真正要解决的是“让新客户快速了解规格和报价”以及“让老客户在线上下单补货”。于是第一版只做了商品目录、在线询价、简易下单两周就上线了。后来数据也证明用户最常用的就是询价和商品浏览复杂的物流功能完全没必要放在第一期。1.3 数据闭环和运营规划要前置很多人开发小程序时完全不考虑数据上线后才想起来要看转化率、复购率结果发现没有埋点、没有统计干着急。我的建议是在需求阶段就同步规划数据埋点方案哪怕第一版只统计关键事件比如访问、加购、提交订单、支付成功。另外要注意小程序不是开发完就结束的它是一个运营工具。你要提前想好谁能帮你分享推广用什么方式激励用户分享用户沉淀在哪个私域池里我在和项目方沟通时经常说一句话“小程序是把流量接进来的水管但水池得你自己挖。” 如果连后续运营动作都没想清楚那开发的每一分钱都可能打水漂。2. 技术选型原生、uni-app、Taro还是SaaS平台2.1 微信原生小程序控制力最强但只覆盖一个平台如果你只做微信小程序且团队里有熟悉小程序的开发者原生开发是最稳妥的方案。它的优点是没有中间层性能最好新增功能可以第一时间用到调试也最方便。尤其是涉及复杂动效、地图、蓝牙、硬件交互这类能力时原生优势非常明显。我之前帮一家做体脂秤硬件的客户做过配套小程序需要蓝牙连接设备、实时读取数据、绘制波形图表这种场景用原生开发最顺手因为微信官方对蓝牙接口的封装在原生环境里最稳定跨端框架偶尔会有兼容差异。缺点是只能跑在微信里以后如果还想做支付宝小程序、抖音小程序代码不能复用得重写一遍。2.2 uni-app跨端开发一套代码多端复用适合快速上线如果你的业务一开始就规划“微信H5App”多端覆盖或者团队技术栈是Vue那uni-app是很合适的选择。它是目前国内用得最多的跨端框架之一一套Vue代码可以编译到微信小程序、支付宝小程序、H5、iOS和Android。我自己的经验是对于商城类、内容展示类、工具类项目uni-app的开发效率非常高。因为页面结构、组件、API都帮你封装好了团队里熟悉Vue的同学几乎零成本上手。而且它的插件市场有大量现成组件比如商城、支付、地图、图表能省不少时间。但要注意跨端框架不等于“一次编写处处运行”还是会有平台差异需要处理。比如微信小程序的登录逻辑、支付流程和H5的完全不同需要针对不同端写条件编译代码。另外如果项目特别依赖微信原生能力比如蓝牙、NFC、微信运动用uni-app也能做但要额外处理的东西会多一些。2.3 Taro、第三方SaaS和源码二开适合什么场景除了uni-appTaro也是一个不错的跨端方案它基于React语法如果你的团队是React技术栈选Taro会更顺手。Taro对多端支持和工程化配置做得比较完善适合中大型项目。还有一些项目方尤其是预算有限或想尽快上线的会考虑第三方SaaS平台直接购买一套已经做好的小程序商城系统按月付费。这种方式确实便宜、上线快但有个明显短板数据和用户资产都在别人的平台上定制功能受限以后想搬家很难。我之前遇到过一位做食品电商的客户图便宜先用SaaS平台做了个小程序后来想加一个分销裂变功能平台不支持只能推倒重来钱花了还耽误时间。还有一类是购买源码二开比如网上常见有“苗木交易小程序源代码”出售几百块就能买到。我劝你慎重这类源码质量参差不齐可能存在安全漏洞、代码冗余最关键的是你买到的是“别人的业务逻辑”要改成适合自己的场景改造成本可能比从零开发还高。2.4 选型对照不同场景下的技术路线建议维度原生小程序uni-appTaroSaaS平台源码二开多端支持仅微信微信支付宝H5App微信H5React Native平台内多端取决于源码性能最佳良好良好一般不稳定定制能力最强强强弱受制于原代码开发成本高中中低表面低实际不确定适合场景重度依赖微信能力多端需求、快速上线React技术栈团队快速验证、预算极低仅当源码质量非常高总结一下我的决策逻辑只做微信、重依赖原生能力选原生多端覆盖、Vue团队选uni-appReact团队选Taro想快速测试市场可以先用SaaS但要做好数据迁出的准备。不要因为“便宜”而选一个未来会卡住你的方案技术债迟早要还。3. 核心功能开发中的关键决策与实操细节3.1 用户登录别再用“授权弹窗”吓跑用户小程序登录是一个被讨论烂了但又绕不开的话题。很多新手一开始就在启动页弹授权框让用户点“允许获取你的昵称头像”结果转化率掉了不少。微信早已改了规则获取用户头像昵称不再自动弹出而是需要用户手动点击触发而且现在拿到的头像昵称是“微信头像”和“微信昵称”不能直接用于登录态。正确做法是静默登录在小程序启动时调用wx.login获取 code把 code 传给后端后端再通过code2Session接口换取 openid 和 session_key。用户只要打开小程序服务器就能知道他是谁不需要任何弹窗。等用户真正需要用到头像昵称的场景比如发帖、完善资料再引导用户点击授权。这里有个关键点openid 是用户在你这个小程序里的唯一标识不同小程序的 openid 不一样所以不要试图拿 openid 当跨应用的统一用户ID。如果以后要打通公众号、App的用户体系需要用 UnionID 机制需要先绑定开放平台账号。3.2 动态设置标题一个低频但很实用的小功能“小程序动态设置标题”是很多运营同学会提的需求进入不同页面时希望顶部标题根据内容变化或者分享出去的卡片显示不同的标题。实现方式非常简单。静态标题在app.json的window节点里配置navigationBarTitleText这只对全局生效。如果想每个页面单独设置就在页面的.json配置里写{ navigationBarTitleText: 我的订单 }动态设置需要在页面生命周期里调用 API。原生小程序用wx.setNavigationBarTitleuni-app 用uni.setNavigationBarTitle// 以 uni-app 为例 onLoad(options) { const title options.name || 默认标题; uni.setNavigationBarTitle({ title: title }); }更细节的一点是分享标题和页面标题是两回事。分享卡片默认取页面标题但如果想单独控制分享出去的内容可以在onShareAppMessage里指定onShareAppMessage() { return { title: 超值好物点开看看, path: /pages/index/index?id123 }; }我踩过的一个坑是在异步回调里设置标题比如从接口拉取数据后再setNavigationBarTitle需要确保接口返回时页面还在前台。如果用户已经切走会出现标题设置不生效的情况所以建议在onLoad里同步设置一个默认标题接口返回后再覆盖。3.3 顶部导航栏高度与胶囊对齐自定义导航必踩的坑微信小程序的导航栏有“默认导航”和“自定义导航”两种。默认导航不用管微信帮你处理好了。但如果你想要更炫的沉浸式头部或者品牌色和标题栏一体化就需要设置navigationStyle: custom这时候坑就来了不同手机的状态栏高度不一样胶囊按钮位置也不一样。获取胶囊按钮的位置和状态栏高度标准做法是这样// 获取状态栏高度 const systemInfo wx.getSystemInfoSync(); const statusBarHeight systemInfo.statusBarHeight; // 获取胶囊按钮位置 const menuButton wx.getMenuButtonBoundingClientRect();拿到statusBarHeight和menuButton.top、menuButton.height后你可以算出导航栏的总高度const navBarHeight (menuButton.top - statusBarHeight) * 2 menuButton.height;这个公式的含义是胶囊按钮到状态栏底部的距离加上胶囊自身高度再乘2得到整个自定义导航栏的高度。原理是胶囊按钮在导航栏里是垂直居中的上下间距相等。实操中我建议把这段计算封装成全局方法在App.vue的onLaunch里获取后存到全局变量避免每个页面重复计算。另外自定义导航后一定要处理安全区否则你的内容可能会被刘海屏遮挡。页面根节点要加上padding-top: 状态栏高度 导航栏高度或者用 CSS 变量env(safe-area-inset-top)配合处理。3.4 单选框、长按拖拽排序等交互组件有朋友会问“小程序单选框怎么做”。原生组件里radio-group和radio就能满足大多数需求uni-app 里对应的是radio-group和radio用法几乎一致radio-group changeradioChange label radio value1 checked /选项一 /label label radio value2 /选项二 /label /radio-group注意label一定要包住radio和文字否则点击文字无法选中这是很多新手忽略的细节。这个功能和原生 HTML 的label逻辑是一样的本质是扩大点击热区。至于“长按拖拽滚动”常见于排序、收藏夹管理等场景。实现思路有两种一种是小程序官方提供的movable-area配合movable-view把可拖拽元素放进去监听touchmove事件判断位置变化另一种是在长按事件longpress触发后将列表切换为可排序状态通过touchstart、touchmove、touchend自行计算位移。我自己做拖拽排序时更倾向于第二种方式因为movable-view在列表较多时性能一般且对复杂布局的适配不够灵活。简单说就是长按进入编辑模式手指移动时实时计算目标元素的坐标松手后交换位置再用v-if或wx:if刷新列表。这里有个技巧拖拽过程中要给被拖拽元素加一个半透明效果和轻微放大视觉反馈清晰了用户体验会好很多。3.5 H5内嵌与定位获取uniapp开发H5嵌入公众号的坑现在不少业务很典型本身有微信公众号想在小程序里嵌入H5页面或者在公众号H5里获取用户定位。uni-app开发H5嵌入微信公众号获取定位是一个高发问题区。先明确一点H5页面在微信内置浏览器里获取定位和在小程序里获取定位机制完全不同。小程序里用wx.getLocation配好权限声明就行但在公众号H5里你需要走微信JS-SDK的getLocation接口这需要公众号具备“地理位置”接口权限并且要在后台配置JS接口安全域名。用uni-app开发H5时我的建议是不要在应用层直接调uni.getLocation而是先判断环境// #ifdef H5 // 判断是否在微信内 const ua navigator.userAgent.toLowerCase(); if (ua.indexOf(micromessenger) -1) { // 调用微信JS-SDK的getLocation } else { // 调用浏览器原生Geolocation } // #endif一个常见报错是“config:fail invalid signature”这通常是后端生成签名时的URL和当前页面URL不一致导致的。微信JS-SDK签名时用的URL是当前页面的完整地址不能去掉#后面的部分也不能加多余的参数。这个问题我遇到过好几次排查到后面发现都是签名URL不完整很折磨人。3.6 跳转外部链接与业务scheme生成、触发、避坑全流程“微信小程序跳转链接weixin://dl/business” 这类问题本质是想解决“从外部环境打开小程序”的需求。这里要区分几个概念URL Link / URL Scheme官方提供的从H5、短信、邮件等外部场景跳转到小程序的方式。需要在微信公众平台后台生成可以携带参数。weixin://协议这是微信客户端的内部URL Schemeweixin://dl/business是微信内部用于拉起“微信支付-商户”相关页面的协议不是一个你可以随意用于自定义跳转的通用接口。如果业务需要从自有App跳转到小程序官方推荐使用wx.openBusinessView或者开放平台的「App跳转小程序」能力需要绑定后配置。很多开发者在网上看到一段weixin://dl/business的代码以为修改参数就能跳到任意小程序实际是行不通的微信对协议做了大量限制和校验。实操建议外部流量引导进小程序优先使用URL Link它可以在微信内或微信外直接拉起小程序而且可以动态设置路径和参数。尤其在广告投放场景URL Link是主流方案。生成URL Link后统一定义跳转目标路径和query参数并在小程序侧做好参数接收和异常兜底比如用户从链接进入时没有登录态要能自动跳转到登录页而不是白屏。3.7 小程序商城与支付微信支付接入的关键决策做商城类小程序支付是绕不开的环节。这里说的不是技术细节而是业务决策。首先个人主体的小程序无法开通微信支付必须升级为企业主体或个体工商户主体。如果你只是想测试可以用测试号但正式上线必须用企业资质。微信支付的接入流程是先到微信支付商户平台注册商户号再将商户号与小程序AppID绑定签约对应产品JSAPI支付下载API证书后端在统一下单接口申请支付参数前端调用wx.requestPayment拉起支付。我提几个容易踩坑的点商户号主体和小程序主体必须一致或者有授权关系否则审核过不了。支付回调地址必须是HTTPS而且不能带参数接口要能处理重复通知因为微信会多次回调。退款是原路返回要在下单时保存订单金额和用户openid退款接口需要传商户订单号和退款金额别把金额写死。支付体验不是只点一下“立即购买”那么简单真实用户会遇到余额不足、支付中断、回调延迟等各种情况订单状态要设计成“待支付—已支付—已发货—已完成”多态并给用户一个“重新支付”的入口。另外现在小程序里最流行的分销裂变、拼团、秒杀这些玩法本质上都是“订单支付分享”的组合。第一版不要急着全上先把基础的下单支付跑通再逐步叠加营销能力稳定性优先。3.8 uniapp项目从开发到真机预览环境配置与工程细节用uni-app开发微信小程序环境搭建很简单安装HBuilderX新建uni-app项目在manifest.json里配置微信小程序AppID然后点击“运行到小程序模拟器”。但很多人到真机预览时就出问题了。真机预览的前提是在微信公众平台后台把开发者的微信号加入项目成员并在开发者工具里开启“服务端口”。平时开发时用测试号无所谓但要真机预览和上传发布必须用正式AppID而且小程序后台还要配置服务器域名。manifest.json里有个特别容易忽略的项微信小程序基础库版本。有些API需要比较高版本的基础库才支持但用户手机上的微信可能比较旧。我一般建议在manifest.json中设置一个合理的「最低基础库版本」同时用wx.canIUse做能力检测避免在低版本设备上报错。另外在HBuilderX里运行到微信开发者工具时如果提示“项目导入失败”大概率是微信开发者工具的“服务端口”没开或者HBuilderX和微信开发者工具版本不匹配。处理方式打开微信开发者工具设置-安全设置-打开服务端口重启两边再试一遍绝大多数问题都能解决。4. 合规、备案与上线容易被忽视的“隐性成本”4.1 小程序备案与备注信息怎么填从某段时间开始微信小程序新上线必须完成ICP备案这和网站备案逻辑类似但走的是微信公众平台的后台「小程序备案」入口。流程上要填写主体信息、服务内容、前置审批项等提交后由相关通信管理部门审核一般几个工作日能下来。经常有人问“小程序备案备注信息怎么填”。以我的经验这里的“备注”一般指的是服务内容备注也就是向审核方说明这个小程序具体提供什么服务。要注意不要写“互联网信息服务”这种空泛的话要写具体比如“提供在线鲜花购买与配送服务”。如果涉及新闻、出版、教育、医疗、药品、金融等特殊行业需要额外的前置审批文件比如ICP许可证、药品经营许可证等一定要提前确认。服务内容要和实际功能一致否则容易被驳回或下架。备案过程中小程序可以先开发、先内测但备案完成前不能发布上线。所以建议项目立项时就把备案提上日程不要等开发完了再备案白白等几周。我遇到最典型的项目延期案例就是因为开发很快、备案等了一个多月。4.2 用户隐私保护指引与收集信息声明随着合规要求越来越严小程序审核对“隐私保护”的检查力度明显加大。你的小程序如果用到getLocation、chooseImage、getPhoneNumber等接口必须在「小程序后台-设置-服务内容声明-用户隐私保护指引」中明确说明收集了哪些信息、用途是什么。这里容易踩坑的是代码里调用了wx.getLocation但隐私保护指引里没有声明或者声明了“获取位置”但页面上没有明确告知用户用途。审核时会被拒。还有一个细节基础库版本较高后隐私协议必须弹窗征得用户同意再调用隐私相关接口很多老项目代码里没做这个流程上线后因为隐私弹窗问题被用户投诉甚至被下架。所以我在做项目时会专门有一个“隐私合规自查”清单涉及哪些隐私接口、弹窗文案怎么写、授权拒绝后怎么引导、数据存哪里、保留多久。不要觉得麻烦这是现在上线的硬门槛。4.3 审核驳回常见原因与应对微信审核是很多项目上线的“最后一关”也是最不可控的一关。我总结了几类高频驳回原因类目选择错误比如做电商却选了“工具”类目审核不通过。要提前在后台查看你想做的功能对应哪个类目并准备资质。页面内容不完整审核人员会真实点击你的小程序如果某个入口点了没反应或者页面是空的很容易被拒。诱导分享文案写“分享给好友才能解锁”这违反规定。分销和诱导分享的边界要拿捏好。测试账号未提供如果你的小程序需要登录才能使用最好提供一个体验账号给审核人员否则对方进不去核心页面大概率被拒。图片来源不规范用了无版权图片、或涉及品牌侵权的图片都会导致驳回。应对之道没有捷径提前阅读最新版《微信小程序平台运营规范》把容易踩的坑在开发阶段就规避掉。另外第一次提交审核前建议自己先走一遍用户流程把所有能点的按钮都点一遍模拟审核人员的心态去看自己的产品。4.4 域名、服务器与HTTPS上线前的技术底座小程序的网络请求有严格要求必须使用HTTPS协议且域名必须在微信公众平台后台配置为“request合法域名”。开发阶段可以勾选“不校验合法域名”但正式上线必须配置好。服务器选型也影响体验。前期用户量不大时一台低配云服务器足够但如果要做直播、秒杀这类高并发场景就要提前评估负载均衡和带宽。我的建议是第一版按预估峰值流量的3到5倍准备资源同时做好监控告警上线后根据真实流量调整。另外要注意小程序里无法直接使用IP地址访问接口必须绑定已备案的域名并且域名必须也已备案。这个时常被忽略开发完才发现域名没备案整个上线计划往后推迟一两个月。5. 预算、报价与选择开发团队别只看“多少钱”5.1 小程序开发报价的构成以及一份参考报价表模板很多项目方一上来就问“开发一个小程序多少钱”这个问题真没法用一句话回答报价的差距可以相差几十倍核心在于需求复杂度、页面数量、是否有后端、是否需要运营后台、是否需要持续迭代。我整理过一份常规的报价项目构成表供你参考项目说明计费方式需求梳理与原型图确认功能清单、页面流程按项目UI设计页面视觉设计、切图按页面小程序前端开发前端页面与交互按项目或按工时后端开发接口、数据库、管理后台按项目或按工时微信支付/登录等第三方接入对接微信支付、短信等按项测试与修复功能测试、兼容性测试按项目服务器与域名云服务器、域名、备案按年运维与迭代上线后支持和后续需求按工时或按月基于这个框架模板类小程序可能几千到一两万定制化程度高的商城类小程序通常在几万到十几万涉及硬件对接、AI能力或者复杂业务的预算要准备到二十万以上。要提醒的是报价不是越低越好。我见过不少客户贪便宜买几千块的小程序最后发现代码质量差、扩展性差重做等于付两次钱。5.2 如何判断一个报价是否合理以及避坑清单判断报价是否合理的核心是看对方有没有认真了解你的业务。一个靠谱的开发公司或开发者会先问很多问题你的用户是谁核心流程是什么有没有后台管理需求数据量多大有没有时间计划如果对方不沟通细节直接报价那给你的大概率是套模板的通用方案。另外如果对方承诺“什么都能做”且价格极低要格外小心。小程序开发领域有大量转包的情况商务接单技术再转包给其他人质量和服务都没保障。避坑清单合同里必须写明源码归属。是全部交付还是只交付小程序端代码后端代码给不给数据库结构给不给。否则后期想换人维护会非常被动。确认域名和服务器账号归属。如果域名和服务器是用对方账号购买的解约时的交接成本很高一定要明确过户规则。分阶段付款不要一次付全款。建议按“签约—原型确认—开发完成—上线验收”几个节点支付。明确售后维护期。上线后Bug修复是否免费周期多久都写进合同口头承诺不算数。5.3 找外包、自建团队还是买SaaS平台一个决策矩阵到底自己招人做、找外包公司还是直接用第三方平台我给出的判断标准是短期验证、预算有限优先考虑SaaS平台或模板类方案快速上线跑通业务但要做好数据迁移的心理准备。长期投入、业务复杂、有差异化需求建议找专业开发团队外包因为预算和范围可控不用养团队。平台级产品、需要快速迭代才需要考虑自建技术团队。自建团队的成本很高一个完整的开发组产品前端后端测试一个月的人力成本就是一笔不小的开支如果业务量没起来很容易拖垮现金流。关于找开发公司还有一个常见误区是搜索“北京小程序开发公司”这类关键词。不是说搜不到好公司而是你得具备识别能力。我建议重点看三点他们是否做过和你业务类似的案例案例的代码质量是否可以验证沟通时是否愿意从业务角度给你建议而不是一味说“能做”。真正专业的团队会告诉你哪些功能现阶段没必要做哪些必须在第一版做。6. 常见问题与实战排查上线前后的高频故障6.1 高频问题速查表问题描述常见原因排查与解决页面白屏接口报错、JS异常、域名未配置打开调试器看Console报错确认request合法域名已配置并支持HTTPS分享卡片标题不对分享回调里没设置title在onShareAppMessage明确返回title、path、imageUrl定位失败隐私声明缺失、用户拒绝授权、基础库版本低检查隐私保护指引是否声明getLocation推荐用户升级微信支付调不起来商户号未绑定、AppID不一致、签名错误核对后台证书、商户号和小程序AppID的绑定关系看支付回调日志真机预览空白未添加开发者微信号、服务端口未开在小程序后台添加体验成员打开开发者工具服务端口审核被拒类目不符、内容不完整、诱导分享对照运营规范逐条自查准备测试账号上传代码时“分包过大”主包超过2MB限制把静态资源放CDN按需引入组件使用分包加载自定义导航栏错位忽略了胶囊和状态栏高度使用getMenuButtonBoundingClientRect动态计算高度H5定位无响应JS-SDK签名失败检查签名URL完整性公众号后台绑定JS接口安全域名数据接口被恶意调用无鉴权、无频率限制后端统一校验token重要接口加签名和限流6.2 我踩过的几个坑与复盘第一个坑是分享标题设置失效。有一次做活动页分享出去的卡片title总是默认的“小程序”排查了半天发现是页面里用了wx.setNavigationBarTitle修改页面标题但分享回调里没有重新设置。小程序的分享卡片默认取页面标题如果你在onShareAppMessage里只返回了pathtitle 会去读当前页面导航栏标题而某些异步场景下这个值是空的。所以做分享运营时分享回调里的title一定要显式写死不要依赖默认值。第二个坑是自定义导航栏在部分安卓机上出现错位。当时设计稿是根据iPhone的刘海屏适配的用了一个固定的statusBarHeight结果在小米、华为等机型上状态栏高度和胶囊位置都和iPhone不同标题跑偏。后来改成动态计算胶囊高度和位置才彻底解决。第三个坑是用户授权被拒绝后的引导缺失。有一版小程序需要定位权限老代码在用户拒绝授权后没有任何提示用户就停在了一个没有数据的空白页上后台发现定位失败的用户占了近一半。后来在拒绝授权的回调里增加了引导弹窗告知用户“需要开启定位才能使用附近门店功能”并附上前往设置页的按钮数据一下子就正常了。第四个坑是小程序后台更新了隐私接口声明后才出现的新错误。有一段时间很多开发者反馈调用wx.getLocation时报getLocation:fail the api need to be declared in privacy agreement原因是后台没有在“用户隐私保护指引”里声明该接口或者基础库版本过旧。处理办法是第一时间在后台补声明同时提示用户升级微信版本。6.3 给项目管理和长期迭代的几个建议小程序开发不是一锤子买卖上线只是开始。结合我的经验给几个长期迭代的建议第一保留一个小而全的“运营后台”。哪怕最开始只有管理员能改轮播图、改商品、看订单也比把所有配置写死在代码里强。很多需求在开发时觉得“这个改一下很快”但没有后台的话每次改动都要发版运营效率极低。第二建立版本节奏。小步快跑每周或每两周发一个版本每次只加少量功能用户反馈与开发迭代并行。微信审核需要时间尽量不要憋一个月才发一个大版本风险太大。第三后端预留扩展点。比如一开始就把订单状态设计成可扩展的、商品属性用JSON存储而不是固定字段、支付和营销逻辑做接口化。这些看起来是“过度设计”但当业务增长时你会感谢当初的自己。一点个人体会做了这么多年小程序相关项目我最大的感触是技术从来不是最难的最难的是在正确的时间做正确的取舍。同样一个商城需求有的团队两个月上线开始赚钱有的团队半年还没走出需求评审差别不在代码能力而在于决策效率。如果你正准备启动一个小程序项目我建议你把本文提到的几个决策点挨个过一遍业务角色是什么、目标用户什么时候用、用原生还是跨端、第一版做哪些功能、备案能不能同步启动、找谁开发和怎么验收。这些问题有了答案你的小程序开发路径就清晰了线上渠道的拓展自然水到渠成。最后再分享一个小技巧上线后一定要在微信公众平台后台开启“体验版”给核心用户试用收集真实反馈后再全量发布。很多问题在体验阶段就能暴露别等所有用户都涌进来才后悔。