微信小程序开发复盘：上线三个月，改的都是最初没写的需求

微信小程序开发复盘：上线三个月，改的都是最初没写的需求

用户点开小程序，到完成一次预约，中间要经过四跳：加载分包、换取登录态、请求业务接口、接收回调。链条上没有哪一跳特别难，难的是这些跳之间那些默认的约定，第一版通常不会写进需求文档。

把一个会员预约类项目上线后三个月的改动清单摊开看，能归类的有四十多项。其中七成落在三个地方：登录态怎么续、分享出去的路径落到哪、消息用什么方式触达。这三件事在立项会上几乎不会被讨论，因为它们看起来是"技术细节"。

这篇复盘按问题拆，不做流程罗列。微信小程序开发真正的分水岭，往往就在这些没人主动提的地方。

核心判断：微信小程序开发的成败，八成取决于立项时有没有把登录态、分享路径与平台边界写成约定，而不是取决于功能清单有多长。

为什么第一版总漏掉分享路径？

因为内部演示时没人分享。评审会上大家用测试账号登录，直接点进目标页，一路顺畅。真上线后，用户的第一入口常常是别人转发的一张卡片，而卡片落地的页面在开发时压根没配。

常见的结果是这样：分享出去打开是首页，用户要找的商品或活动得自己再搜一遍。看起来只是多一步，转化率会掉得很明显。

正确的做法是在原型阶段就把分享路径画出来，标清分享卡片从哪来、落到哪个页面、带什么参数、未登录时怎么处理。四条写清楚，开发量增加不多，返工能省一大截。

登录态为什么要单独设计？

小程序的登录不是一次动作，而是一条会过期的链路。用户授权拿到的凭证有时效，过期后要用静默方式重新换，换不到才弹授权。这条链路的每一个分支，都要有明确的界面反馈。

多数第一版只做了"能登录"这一条主干。等到凭证过期，用户看到的是空白页或者一直转圈，然后卸载。

一个可用的设计至少包含三层：静默续期、失败降级到手机号授权、极端情况下允许游客浏览但限制下单。三层都做，开发周期大概多一周，但这周能挡掉上线后最常见的投诉。

这类细节在小程序开发的关键概念梳理里也有提及，值得在立项阶段一起过一遍。理解小程序与普通网页的差别，是微信小程序开发绕不开的第一课。

能力边界到底卡在哪？

边界问题在第二个月集中爆发。业务方提的需求，用网页思路看都合理，放到小程序里就撞墙。

几个高频的卡点：安装包体积有上限，图片和视频资源要放出去；后台不能常驻，定位与蓝牙只能在页面活跃时用；跳转外部链接要走特定配置，域名必须提前备案并加入白名单；消息推送要靠用户主动订阅，不能像短信那样想发就发。

这些限制不是缺陷，是平台设计。项目启动时把它们列成一页纸，业务方提需求前先对照，比开发到一半再解释有效得多。

这一类判断在长沙小程序开发服务的项目里反复出现，原因是业务方只看功能，开发方只看接口。

术语上也需要先对齐。小程序不是"更轻的网页"，它是一套运行在特定宿主里的应用，页面渲染、网络请求、本地存储都受宿主规则约束。云迈科技在项目启动会上通常会让产品经理把这一页打印出来贴在会议室，就是因为边界问题越早暴露越便宜。

提审为什么会被驳回？

提审被驳回是常态，不是意外。最常见的原因有四类：类目与功能不匹配、页面存在诱导分享、个人信息收集没有说明用途、内容涉及需要资质的经营项目。

这四类里，前三类都能在开发阶段规避。类目在注册时就该按实际业务选，选了电商类目却做社交功能，审核一眼就能看出来；诱导分享的判定标准写在平台规则里，做活动页时对照即可；收集手机号、位置、相册权限时，弹窗要写清用途，并给出不授权的降级路径。

第四类最麻烦，涉及资质。教育培训、医疗健康、金融理财这类业务，提审前要准备好对应材料，否则代码再规范也过不了。项目排期里应该给提审留出两轮迭代的时间，也就是大约四到六个工作日。

一个实用的做法是把审核规则整理成一页清单，交给产品经理在原型阶段逐条对照。这件事花半天，能省掉上线前的反复。

时间是怎么被吃掉的

复盘这个项目的排期，实际的分布大致是这样。

• 第 1 到 2 周：需求梳理与原型确认，改动两次，范围收敛。
• 第 3 到 6 周：主流程开发，含登录态、预约、支付三条链路。
• 第 7 周：联调与真机测试，机型适配占了四成时间。
• 上线当周：提审与驳回修改，两次，累计三天。
• 上线后 30 天：改动 47 项，其中 33 项属于前述三类遗漏。

排期表上没有哪一项特别长，问题在于提审周期和真机适配这两段经常被估成零。它们不是可压缩的工作量，是固定开销。

顺带说一句适配：安卓机型的分辨率与系统版本组合多，微信小程序开发里最容易出问题的是支付回调与页面高度计算。前者在不同机型上返回值不一致，后者会被底部安全区影响。测试阶段至少要覆盖三档屏幕与两个系统版本，这段工作量写进排期，比上线后救火便宜。

哪些指标要到第三个月才动？

上线首月的数据通常好看，因为来的多是老客户和内部推荐。真正能看出问题的，是第三个月的数字。

建议固定看四个：首屏可交互时长、次日留存、预约完成率、分享带来的新用户占比。前两个反映体验，后两个反映路径设计是否成立。首屏时长超过两秒半，留存会明显下滑；分享占比长期低于百分之五，说明分享路径基本没跑通。

这四个指标不需要复杂埋点，页面级事件加上来源参数就够。关键是上线前就埋好，否则第三个月想看也看不到。

埋点本身也有个坑：只埋点击不埋曝光。分享按钮被点了多少次容易统计，被看到多少次却很难，导致转化率的分母永远是错的。把曝光也补上，路径问题才看得清。

什么时候不建议做小程序？

反向说一句：不是所有业务都适合。如果产品重度依赖后台常驻、需要长时间高精度定位、涉及大量本地文件处理，小程序的能力边界会成为长期负担，做成原生应用更合适。

还有一种情况：业务本身低频到一年用两次，用户不会为它保留一个入口，做完也是沉睡。这类需求先验证业务，再谈载体。

判断标准并不复杂，把核心动作拆成五步，看其中有几步受平台限制。超过两步，就该重新评估载体，而不是硬在小程序里绕。

几个常被问到的问题

问题一：自己养团队做，还是找外部团队？取决于这条业务线是否需要持续迭代。一年只改两次的项目，外部团队的综合成本更低；每周都在改的，内部团队响应更快。

问题二：一套代码能不能同时上多个平台？可以，但适配成本不会消失，只是从开发阶段挪到调试阶段。跨平台方案适合业务逻辑简单、界面统一的产品。

问题三：上线后谁来维护？维护包含提审合规、接口变更适配、故障响应三块。前两块是周期性工作，第三块看响应时效，签约时把这三块的服务边界写清楚，比笼统写"提供售后"有用。云迈科技在这类项目里会把提审被驳回的责任划分写进合同，因为这是最常见的扯皮点。想了解团队配置与分工，可以看小程序开发团队怎么搭；代码归属与交付物，小程序源码交付该交什么有逐项说明。

写在最后

回到开头那个判断：微信小程序开发里真正贵的不是写代码，是那些被默认跳过、后来又必须补上的约定。把分享路径、登录态、能力边界三件事在第一版就写清，三个月的改动清单能少掉一半。

湖南云迈科技有限责任公司在长沙做过的同类项目里，这套前置约定的做法已经固化成启动会的固定环节，产品、开发、业务三方各签一次确认。长沙与湖南本地的业务场景差异不小，会员体系、预约规则、门店结构都不一样，建议先把自己的核心动作拆成五步，再对照平台边界逐条评估，需要沟通具体场景时，带着这份拆解来聊会更高效。