昆山小程序开发全流程：需求、原型、审核到上线

一个周四下午，运营把活动链接发进群里，点开却是「页面不存在」；开发查了半天，发现小程序还卡在审核，而活动海报已经印好了。类似的时间差在昆山小程序开发项目里不算稀奇：需求、原型、开发、提审、发布各有各的节奏，只要有一段没对齐，上线日期就会被推着走。把全流程拆成可核对的阶段，比每天追进度管用。

本文要点

• 昆山小程序开发流程先把「不做什么」写清，再列 MVP 功能清单与资质前置项
• 原型阶段定页面层级与 tabBar，空态、加载态、授权拒绝要一起画
• 微信小程序上线步骤里，类目资质、隐私协议与合法域名是常见驳回点

需求边界与功能清单

需求阶段容易犯的错，是把想做的全写进一期。功能一多，页面数、接口数、提审时要说明的内容一起涨，工期和返工都跟着涨。比较稳妥的做法是先把边界划出来：这一版要解决哪一件事，哪些明确不做。

「不做什么」要写成可核对的句子，例如「一期不做直播、不做分销分佣、不做跨平台 H5 版本、不接自建即时通讯」。边界写清楚之后，功能清单才有收敛的依据。

小程序定制开发里还有一类前置项，不属于功能，却决定项目能不能按期提审，需要单独列一张表跟踪：企业或个体工商户主体注册、小程序类目选择、行业资质（如食品经营许可、ICP 备案、办学许可等按类目而定）、微信支付商户号申请与绑定、服务器域名备案、HTTPS 证书签发、管理员与开发者权限绑定。这些事项的办理周期不在开发团队控制范围内，越早启动越好。

常见情形是：功能全部开发完，支付商户号还在走审核，提审时支付页面只能放演示数据，被判「功能不完整」退回。把资质与账号类事项并行推进，比排在开发后面稳妥得多。需求文档定稿时，建议附一页「前置事项与责任人」，每项写明当前状态与预计完成时间。

原型与页面流程

原型不只是把页面画好看，它要定下页面之间的关系。先列页面清单：启动页、首页、分类、详情、下单、支付结果、订单列表、订单详情、个人中心、关于我们，以及各类弹层。再画跳转关系，说明每个页面从哪来、能去哪、返回到哪。

小程序有页面栈限制，navigateTo 保留当前页继续入栈，层级过深会出现点不动的情况。常规业务把主要路径控制在 5 层以内体验较顺，超出时改用 redirectTo 或 switchTab 收栈。路由方式选错，是原型看着没问题、真机一跑就卡住的常见原因。

app.json 里 pages 数组的顺序决定初始页面，别在联调阶段才发现首页指错了。tabBar 配置 2 至 5 个条目，图标需准备普通与选中两套，路径必须先写进 pages。底部导航的页面不能用 navigateTo 跳，只能用 switchTab，这一条在原型评审时就要标出来。

原型里还要把异常状态画齐。只画「数据正常、网络正常、已授权」的理想路径，开发阶段会不断回头补，测试阶段则集中暴露。

• 空态：列表无数据、搜索无结果、购物车为空
• 加载态：首屏骨架屏、分页加载中、提交按钮防重复点击
• 失败态：请求超时、接口 5xx、支付失败与取消
• 权限态：拒绝定位、拒绝授权手机号、未登录访问受限页
• 边界态：库存为 0、活动已结束、金额为零、长文本溢出

「昆山小程序开发流程」走到原型这一步，交付物应该是一份页面清单、一张跳转关系说明、一套带状态标注的原型图，以及一份接口字段的初步约定。评审通过后再进开发，比边做边改省工。

设计与前后端开发

设计稿常以 750rpx 为基准宽度。rpx 是小程序自带的自适应单位，在 iPhone 6 宽度下 1rpx 约等于 0.5px，换到不同屏宽会自动换算，比写死 px 省心。字号、间距、按钮高度建议抽成变量，组件（按钮、卡片、空态、价格）做成可复用块，后面改版不用逐页调。

包体积是开发阶段要盯的硬指标。主包有 2MB 上限，整包（含全部分包）有 20MB 上限，单个分包也受 2MB 限制。图片尽量走 CDN 或云存储，别塞进代码包；活动页、次要业务拆进 subpackages，用 preloadRule 配置预下载，用户进首页时后台静默拉取，切过去不觉得卡。独立分包适合不依赖主包就能打开的活动页，但要注意它拿不到主包的公共逻辑。

后端部分先把三件事定下来。其一，域名白名单：在小程序管理后台配置 request、uploadFile、downloadFile、socket 合法域名与业务域名，全部要求 HTTPS 且证书有效，本地联调可临时开启「不校验合法域名」，提审前必须关掉。其二，登录链路：前端拿 code 交给服务端，服务端调 code2session 换取 openid、unionid 与 session_key，再下发自定义登录态；access_token 由服务端缓存（常见有效期 7200 秒），不要放在前端。其三，接口约定：统一响应结构如 { code, data, message }，分页参数与错误码列表写进文档，前后端按同一份字段表开发。

交易相关接口要单独考虑幂等。用户连点提交、支付回调重复推送，都可能生成两笔订单：服务端用业务订单号加去重约束，支付回调按交易号去重，库存扣减与订单创建放在同一事务里。这些是后端细节，但小程序定制开发验收时往往就卡在这里。

云开发与自建服务器各有取舍：云开发省去域名备案与运维，适合轻量业务；自建服务器便于复用现有 ERP、官网或会员数据，接口与权限可控，但要自己承担备案、证书、扩容与监控。选型时按「是否要与企业现有系统打通」来判断，比按开发习惯判断更实际。

测试项与真机验证

模拟器跑通不等于真机能用。真机验证要覆盖不同系统、不同微信版本、不同性能档次的设备，尤其低端机上的长列表与图片加载，模拟器里往往看不出问题。

• 系统覆盖：iOS 与 Android 各测，含较旧系统版本与近两代微信客户端
• 设备覆盖：至少一台低端机，检查首屏耗时、长列表滑动、多图页面
• 网络：弱网、断网、接口超时，确认有提示而不是白屏；恢复后能重试
• 授权：拒绝定位、拒绝手机号、拒绝通知，逐项看后续流程是否被卡死
• 支付：成功、失败、取消、重复回调四类，核对订单状态与幂等
• 交互：下拉刷新、触底加载、分享卡片、后台切前台、锁屏返回
• 分包：首次进入分包页的加载提示、预下载是否生效
• 适配：刘海屏与底部横条，用 env(safe-area-inset-bottom) 处理安全区
• 键盘：表单页键盘弹起后按钮是否被遮、光标是否跳动

工具上，开发版与体验版配合真机调试、vConsole 查看日志，用 getWindowInfo 一类接口读屏宽与安全区做适配，别再依赖已不推荐的老接口。测试阶段输出一份用例表，每条写明前置条件、操作步骤与期望结果；缺陷按「阻断／一般／建议」分级，阻断项不清零不提审。

遇到过的一类情况是：提审用的测试账号只在开发手机上登录过，审核同学换台设备打开就提示「账号不存在」，直接被判功能不完整。测试账号、演示数据、功能路径说明要当作提审材料的一部分准备，不能等被驳回再补。

平台审核与常见驳回

微信小程序上线步骤里，提审是外部环节，节奏不完全由项目组控制，但驳回原因大多可预防。下面这张表按「原因—说明—处理」整理，提审前逐行对照一遍。

提审材料建议打包成一个文件夹：测试账号与密码、功能路径说明（从首页点几步能到核心功能）、关键流程录屏、资质扫描件、特殊逻辑说明（如为什么需要定位）。审核时长常见 1 至 7 个工作日，遇到大促或节假日要留缓冲；平台提供加急通道，但名额与适用条件按当期规则来，别把它排进基线计划。

隐私相关条目近两年变化较多。采集手机号、位置、相册、剪贴板等，都要在隐私保护指引里如实声明；涉及地理位置接口的，还要在配置中按要求填写 requiredPrivateInfos 与用途说明。前端的授权弹窗时机与后台声明对不上，是驳回里挺常见的一类。提审前用一台干净设备、一个未授权过的新账号完整走一遍，比在熟悉设备上点两下更能暴露问题。

发布与版本管理

审核通过不等于用户立刻看到新版本。小程序有开发版、体验版、正式版三种形态：开发版只在开发者工具与指定手机上可见，体验版供内部与验收人员使用，正式版才是线上用户看到的那一个。审核通过后还需在后台执行「发布」，这一步常被误以为自动完成。

发布方式有两种。全量发布是一次推给所有用户；分阶段发布（灰度）按用户比例逐步放开，先放小比例观察错误日志与接口状况，再扩大范围。涉及支付、订单或数据结构变更的版本，建议走灰度，留一个可观察的窗口。

• 版本号：按 主版本.次版本.修订号（如 1.2.0）管理，每次提审写明变更清单
• 更新提示：用 wx.getUpdateManager 在启动时检查新版本，提示用户重启生效
• 回退：线上版本异常时回退到上一稳定版，同时排查数据与接口兼容
• 兼容：新版本接口要能服务尚未更新的旧客户端，别一刀切下线旧字段
• 入口物料：小程序码、普通链接二维码、公众号菜单，发布后统一替换
• 代码更新：小程序代码包改动需重新提审，不能像网页一样直接热更，配置类内容可走后台下发

审核期间线上旧版本仍在正常服务，这点要写进上线计划：运营活动若依赖新功能，得等发布完成再对外，不能按「提交审核」的日期印海报。版本号、变更清单、数据库迁移脚本、回滚方案四样准备齐，发布才算可控。更多流程拆解可看 行业动态栏目；小程序开发服务范围见 服务与解决方案。需要一份可直接套用的上线检查表，可以走 免费咨询 索取。

上线后的维护

上线是维护的起点，不是终点。头几周重点看稳定性：前端错误日志、接口 5xx 与超时、支付回调成功率、首屏耗时，按版本分组对比，发现问题能定位到是哪次发布引入的。埋点用 wx.reportAnalytics 或自建上报，事件字典在开发阶段就定好，别等要分析时才补。

业务侧看板按需求建，常见维度是访问、留存、下单漏斗与各页面的流失点。这些是观察运营状况的指标，不是交付承诺，重点在于趋势与异常，而不是拿一个数字去说明项目好坏。

• 证书与域名：HTTPS 证书到期、域名续费、备案信息变更，设日历提醒
• 平台规则：基础库下限版本与低版本兼容、隐私指引更新、类目年审
• 接口声明：地理位置等敏感接口按当期要求维护 requiredPrivateInfos
• 密钥与账号：支付商户号密钥、服务端 access_token 凭据定期轮换，权限按人回收
• 第三方依赖：SDK、组件库、地图与统计服务版本升级，升级后回归核心流程
• 反馈渠道：客服会话、意见反馈入口有人值守，问题能进迭代清单
• 迭代节奏：小版本按月修问题，大功能按季度排，每次都走完整的测试与提审

维护里较容易被忽略的是「规则变更」。平台对隐私、类目、地理位置、虚拟支付的要求会调整，去年能过的版本，未必符合当期规范。安排一个人定期看官方公告与站内通知，比收到下架提醒再处理从容。

把维护事项写成一份交接表，标明负责人、检查频率与上次执行时间，项目换人时不会断档。昆山小程序开发全流程走到这一步，交付物就不只是代码包，还包括账号权限、配置清单、监控看板与这份交接表。

小结

全流程拆开看，是需求边界、原型流程、开发联调、真机测试、平台审核、发布灰度、上线维护七段，每段都有能勾选的交付物。明天就能做的一件事：把正在推进的项目按这七段列一张表，逐段填上当前状态与卡点，尤其把资质、域名、支付商户号这些不在开发控制内的前置项单独标出来。昆山小程序开发流程理顺之后，上线日期才不是靠猜。本文为行业经验与技术分享，不构成效果承诺；具体交付范围、周期与资费以书面方案为准。