微信小程序开发流程这个话题，网上随便一搜就是一堆“注册账号—下载工具—新建项目—写代码—提交审核”的流水账。但真在项目里滚过几轮的人都清楚，流程远没有那么潇洒。从账号主体怎么选、框架用什么，到顶部导航栏高度在不同机型上怎么裂开、真机调试请求死活到不了后端，再到支付、地图、音频这些模块各自埋着什么雷，每一步都可能让新人原地卡住。这篇文章我按自己实际做过的小程序项目路线来拆，不念官方文档，把该准备的、该避的坑、该理解的原理一次讲明白。适合准备入坑小程序开发的初学者，也适合已经写了一阵子、想系统梳理流程的开发者。
1. 开发前的准备：账号体系、开发工具与思维转换
1.1 注册小程序账号到底要选什么主体
注册这一步看起来简单，但主体类型的选择直接决定你的小程序能做什么、不能做什么。个人主体注册门槛低，拿身份证扫个脸就能搞定，一个身份证可以注册5个小程序。但个人主体有很多能力被锁死：没有微信支付、没有部分开放接口（比如一些需要企业资质才能用得上的类目插件）、类目审核也更严格。举个实际例子，你想做个校园跑腿平台，个人主体基本过不了审核，因为这属于“本地生活服务”，必须企业资质。
企业主体需要的资料包括营业执照、法人信息、对公账户验证（或者小额打款验证），审核周期一般在1-3个工作日。如果不是只做个人作品展示，我建议直接注册企业主体。另一个容易被忽略的点是：一个企业主体默认可以注册50个小程序，但如果你用的是个体户执照，很多类目仍然受限，比如电商类的“商家自营”部分类目个体户可以用，但金融、医疗这类就别想了。
注册完成后在mp.weixin.qq.com后台能找到AppID，这个就是小程序的唯一身份标识。很多新手在开发者工具里新建项目时填了测试号功能，结果后面真机预览、上传代码全用不了，就是因为没搞清楚“测试号”和真实AppID的区别。测试号适用于纯本地体验，要真上线，必须在后台找到自己小程序的AppID填进项目里。
1.2 开发工具和框架选择：原生、uni-app还是Taro
工具链的选择是我最想劝新人认真想清楚的一件事。微信官方提供的“微信开发者工具”是绕不开的调试窗口，不管用什么框架，最终都要回到它里面编译预览。区别在于你工程代码怎么写。
原生小程序框架（WXML + WXSS + JS + JSON）是最正统的入门方式，官方文档即时更新，第三方插件兼容性最好。缺点也很明显：语法相对封闭，写起来像是一个“爪镶版Vue”，没法直接在浏览器里跑；以后想编译到支付宝、百度小程序，就得重写。
uni-app（Vue语法）是目前国内做跨端项目的主流选择。它能把一套代码编译到微信小程序、App、H5等多个平台。热词里也经常看到“uniapp开发微信小程序”，说明这个方向确实热。但要注意，uni-app编译到小程序后包体通常比原生大，部分原生组件（比如map、video）在跨端时需要差异化适配。Taro（React语法）同样是跨端方案，适合React技术栈的团队。
从新手角度，我建议一步到位从原生入手，先理解小程序的运行机制，再切到uni-app提升效率顺序会比较顺。如果你直接上手uni-app，遇到很多问题时很难分清是uniapp的坑还是小程序本身的坑。
1.3 从“开发静态网站”思维转换到小程序思维
热词里有“开发一个静态网站的流程”，很多人就是在Web开发里滚熟了想转小程序。这里最需要转换的思维是：小程序不是一个能直接发布的网址，它是一套运行在微信容器里的应用。
传统网站流程是：买域名 → 服务器 → 写前端 → 部署 → 浏览器访问。小程序流程是：注册账号拿到AppID → 写代码 → 在开发者工具里预览 → 上传代码 → 在后台提交审核 → 审核通过后发布。区别在于：
- 小程序前端代码包必须小于2MB（主包限制），超过就要做分包；
- 请求接口的域名必须在后台配置到“request合法域名”里，并且必须HTTPS；
- 没有传统意义上的“刷新网页”，所有页面状态靠Page和App的生命周期管理；
- 前端代码不能直接操作DOM，一切操作都是通过数据绑定驱动视图更新。
这个思维不转换，写出来的小程序大概率是“披着小程序皮的H5”，各种体验问题和审核问题会接踵而来。
2. 项目骨架搭建：全局配置、导航栏与公共模块
2.1 app.json / pages.json：你的小程序地图
不管用原生还是uni-app，你都需要在全局配置文件里声明页面路径、窗口样式、tabBar、分包结构等。原生小程序是app.json，uni-app是pages.json，两者的语义基本对应。
很多新手容易漏掉的配置项有这么几个：
lazyCodeLoading: "requiredComponents"：按需注入代码，能明显减少首包加载量，官方推荐开启。style: "v2"：启用新版的组件样式，会让部分老代码样式有差异，但整体更符合现代还原效果。sitemapLocation：微信索引配置，不影响功能，但正式项目中建议保留，否则后台会有警告。darkmode：如果你不打算适配深色模式，就不要全局开，否则页面会突然变得无法控制。
tabBar这里也要提醒一句：图标文件必须是本地路径，不能是网络图片；list数组下限2个、上限5个；selectedColor和color必填，否则安卓和iOS表现不一致。
我在项目里习惯把页面路径命名成小写字母+连字符的风格（比如pages/order-detail/index）。小程序对页面路径大小写敏感，多人协作时一旦有人用了驼峰命名，很容易在合并代码时产生“路径找不到”的问题。
2.2 顶部导航栏高度到底怎么算：一次定制就让你记住
热词里“微信小程序顶部导航栏高度”出现频率很高，原因很简单：微信小程序的导航栏不是固定高度，它会随机型、系统状态栏、是否开启“自定义导航栏”变化。如果你只是用默认导航栏，系统会自动适配。但一旦你想做沉浸式导航、自定义头部背景、或者在胶囊按钮旁边放自定义按钮，就得精确计算两段高度：
- 状态栏高度（statusBarHeight），通过
wx.getSystemInfoSync().statusBarHeight获取。iPhone X系列大约是44px，普通机型20px左右。注意这个单位是px，不是rpx。 - 胶囊按钮（menuButton）的位置和尺寸，通过
wx.getMenuButtonBoundingClientRect()获取，会返回按钮的top、bottom、width、height等数据。
导航栏的整体高度，业界常用公式是：capsule.top - statusBarHeight + (capsule.bottom - capsule.top) + (statusBarHeight - capsule.top)，简化后其实是capsule.bottom + statusBarHeight - capsule.top。说人话就是：胶囊按钮底部到状态栏底部这段距离，乘以2，再加胶囊高度，大约就是自定义导航栏的总高度。
我写过一个通用的自适应方法，大概长这样：
function getNavBarInfo() { const windowInfo = wx.getWindowInfo(); const menuButton = wx.getMenuButtonBoundingClientRect(); const statusBarHeight = windowInfo.statusBarHeight; const navBarHeight = (menuButton.top - statusBarHeight) * 2 + menuButton.height; return { statusBarHeight, navBarHeight, menuButton, }; }在iPhone X系列上，navBarHeight一般为88px左右，在普通安卓机上一般是64px左右。不要写死这个值，否则换一台机子就错位。用上面的方法动态计算，再设置padding-top: statusBarHeight，height: navBarHeight即可。
2.3 web-view高度适配：一个老生长谈又不得不谈的问题
如果小程序里嵌了H5页面，你会用到web-view组件。这个组件的特性是：它会自动铺满页面，无法直接通过CSS控制高度，也不能放在scroll-view里滚动。官方设计是让web-view占据整个小程序页面，内部页面自己在网页端处理滚动。
但实际项目里总有人想实现在页面上半部分显示web-view，下半部分显示原生内容。这个需求在原生小程序很难优雅实现——如果你在页面中给web-view加了样式，比如height: 80vh，iOS上可以勉强生效，安卓上经常会白屏或者高度异常。
我踩过这个坑后的结论是：如果有“网页+原生组件同屏”的需求，优先考虑用cover-view叠在web-view上面，而不是试图去限制web-view的高度。cover-view是专门用来覆盖在原生组件上的，支持基础样式和简单事件。如果要求更复杂的页面结构，那最好放弃混合，改成纯H5页面内完成所有事情，再通过wx.miniProgram.postMessage回传数据。
2.4 公共样式、rpx换算与安全区
小程序里推荐用rpx做尺寸单位，750rpx就是屏幕宽度。设计图如果是750px宽度，那1px就等于1rpx，换算起来很爽。但rpx有个隐藏问题：它不是真正等比缩放到所有屏幕，在极端宽屏或Pad上可能会有轻微比例失真。如果你要做非常精细的1px边框，建议用px+transform: scaleY(0.5)处理。
安全区适配（底部iPhone横条、顶部刘海）也是公共模块要处理的内容。可以用env(safe-area-inset-bottom)做padding-bottom适配，也可以用wx.getWindowInfo().safeArea。我在全局App.vue或app.wxss里都会加这样的兜底样式：
.safe-area-bottom { padding-bottom: constant(safe-area-inset-bottom); padding-bottom: env(safe-area-inset-bottom); }公共组件方面，胶囊按钮“自定义导航栏”、空状态占位、底部加载更多、toast提示这几个组件建议项目起步时就维护好，后面每个页面几乎都会用到。
3. 核心业务模块开发：登录、支付、地图与音频
3.1 微信登录流程：拿到code只是开始
小程序登录是后端开发的必经关卡。热词里有“java后端实现微信小程序登录”，足以说明这个问题的重要性。流程本身不复杂：wx.login()拿到临时code，把code发给自己的后端，后端用code调用微信的code2Session接口，拿到openid、session_key等信息，再自己生成一个token返回给小程序端。
但这里有几个容易踩的坑：
wx.login()拿到的code有效期为5分钟，且只能使用一次。后端拿到code后如果没能成功调微信接口，这个code就作废了，前端需要重新获取。session_key是敏感信息，只能保存在服务端，不能下发到前端。用它解密手机号、运动数据等敏感信息时，必须严格控制泄露风险。- 不要在前端直接存储
openid并把它当成用户标识来信任。前端是能被反编译和篡改的，所有关键鉴权必须依赖后端签发的token。
Java后端的核心伪代码大概是这种思路：
@GetMapping("/wx/login") public Result login(String code) { // 1. 使用code + appid + secret 调用微信接口 WxLoginResp resp = wxApi.code2Session(code); // 2. 根据openid查用户表，没有则自动注册 User user = userService.findOrCreate(resp.getOpenid()); // 3. 生成自定义token（如JWT或UUID），与redis里的session绑定 String token = tokenService.generate(user.getId()); return Result.ok(token); }token建议设置有效期，小程序端每次请求都放在header里传给后端。用户删除小程序后再进入会重新走一遍登录流程，这是正常的，不必刻意让用户“永远在线”。
3.2 支付流程与苹果IAP的“特殊规矩”
很多小程序的核心变现方式就是支付。微信小程序支付（微信支付商户版）流程是：小程序端先调后端接口创建订单，后端拿到payParams（包括时间戳、随机字符串、包名、签名等）返回给前端，前端调用wx.requestPayment拉起收银台。
如果你用uni-app开发，不要被“支付流程和参数是否相同”这个问题绕晕。成功的实践是：后端统一下单接口都一样，只是前端的调用方式不同。在微信小程序端调用uni.requestPayment时，provider不能自己填死，要用wx.requestPayment原生能力去做兼容层。
更关键的是“虚拟支付”的红线：微信小程序对iOS端的虚拟商品（会员、课程、金币、道具等）一直管控严格。从2017年开始微信就规定，iOS端小程序不得使用非苹果IAP的支付渠道销售虚拟内容。实际表现就是：用户在iPhone上打开小程序，点充值虚拟币时微信会直接弹窗拒绝或者按钮置灰。解决办法严格来说只有两种：一是虚拟商品在iOS端使用苹果IAP（但苹果还要抽成30%），二是引导用户去App或者公众号H5里完成支付。热词里“微信小程序虚拟支付 苹果iap退款”说的是另一种情况：用户通过IAP买了虚拟商品后找苹果申请退款，但苹果退还的钱不会自动回流到你的业务系统，需要后端从苹果服务端接口查询退款状态并同步处理。这属于支付关闭后的售后链路，建议提前在订单状态机里设计好“已退款”这个状态。
我自己的建议是：**如果做工具类小程序，尽量不要碰虚拟支付，绕道H5或App完成交易，省下的踩坑时间比什么都值。**如果是实物电商，直接走微信支付即可，不受苹果政策影响。
3.3 地图接入：百度地图、天地图与定位授权
跑腿、旅游、票务类小程序基本都离不开地图。微信小程序原生带有map组件，地图底图由腾讯地图提供，也可以换成个性化样式。
如果你要使用百度地图的逆地址解析、POI搜索、路线规划，官方建议是使用后台API或JavaScript SDK，而前端定位通过wx.getLocation获取坐标，再把坐标传给百度API。
热词里出现的“uniapp接入天地图适配微信小程序、h5、app”，这个需求通常来自政务或自然资源相关的项目。天地图提供的服务能力在小程序端用WebService API比较稳，但要注意：天地图的部分服务需要申请key并配置请求白名单，并且部分接口返回的数据坐标系是CGCS2000，而微信定位拿到的是WGS84，直接用会偏移。所以接入天地图时，坐标转换这一步不能省。
定位授权也是经常让用户抓狂的点。小程序端wx.getLocation必须声明“位置隐私协议”，并且用户如果拒绝了授权，需要在页面上引导重新打开授权设置页。现在微信对位置信息权限审核很严，如果你的小程序没有明显的位置使用场景（比如外卖配送、地图导航），提交审核时很容易被驳回要求用途说明。
实际开发里我倾向于这样的方案：前端wx.getLocation拿到经纬度 → 后端接逆地址解析（腾讯或高德）返回中文地址 → 前端地图展示具体位置。这样前端代码轻、请求链路清晰，也方便排查。
3.4 MQTT与IoT设备接入：blufi、ONENET这类场景
物联网小程序这两年越来越多，常见形态是“用微信小程序给设备配网”或者“实时查看设备数据”。热词里的“blufi 微信小程序”指的是乐鑫ESP32的一种配网协议，核心思路是通过蓝牙把WiFi的SSID和密码传给设备。在小程序端，需要用wx.openBluetoothAdapter等蓝牙API和设备完成数据交互。这个过程中比较麻烦的是：蓝牙配网时数据分包、校验和握手协议每个设备厂商可能都不一样，建议封装出一个独立模块，方便后续复用。
“导入mqtt.js”则是另一种高频需求。小程序端连接MQTT服务器需要走WebSocket协议（wss），不能走tcp://。连接时要注意：
- 连接地址要写成
wxs://xxxx或者wss://xxxx，具体看你的broker是否支持WebSocket； - 客户端ID必须唯一，否则会互相踢下线；
- 小程序在切后台时WebSocket会被系统挂起，需要重新监听
onShow事件后重连； - 如果使用ONENET等平台，它们的鉴权方式一般是URL里带
apiKey或token，不要把这些明文写在小程序代码里，应该由自己的后端代理鉴权。
下面是mqtt.js在小程序里的一段典型初始化代码：
import mqtt from 'mqtt'; const client = mqtt.connect('wxs://your-broker-url/mqtt', { clientId: 'wx_' + Date.now(), username: 'your_user', password: 'your_password', clean: true, }); client.on('connect', () => { client.subscribe('device/data', { qos: 1 }, (err) => { if (!err) console.log('订阅成功'); }); }); client.on('message', (topic, payload) => { const data = JSON.parse(payload.toString()); // 更新页面数据 });你的后端必须对设备上报的数据做合法性校验，不能直接信任小程序传来的数据，否则恶意用户可以伪造设备状态上报。
3.5 iOS静音模式下播放音乐：音频模块的隐藏客厅
热词里“微信小程序 ios 静音状态下播放音乐”是音频开发的典型问题。iOS设备如果拨到静音键，默认所有的音视频都会静音，但微信小程序里的InnerAudioContext有一个属性叫obeyMuteSwitch，设为false时在静音模式下依然能播放声音。
const audioCtx = wx.createInnerAudioContext(); audioCtx.src = 'https://your-cdn/audio.mp3'; audioCtx.obeyMuteSwitch = false; // iOS上强制要求，静音键下也能出声 audioCtx.play();这个设置主要用于音频播放器、语音消息、背景音乐等场景。但如果你做的是视频播放，video组件在iOS上依然受静音键控制，无法通过一个简单的属性绕过。这个差异很迷惑人，我第一次做语音课程小程序时就栽在这里，同一段音频在安卓上大声，在iPhone静音模式下鸦雀无声，排查了半天才发现是obeyMuteSwitch默认是true。
4. 界面与交互的“老六”坑：滚动、单选框、返回拦截
4.1 苹果手机上不能滑动滚动：原因往往很简单
真机一跑，安卓正常，iPhone页面死活划不动，这类问题在很多提问帖里反复出现。按我的排查经验，90%的原因是外层容器被设置了固定高度，或者是position: fixed元素遮挡了滚动区域。
小程序页面的滚动机制和H5不太一样。默认情况是页面容器本身可以滚动，不需要给scroll-view。如果你用了scroll-view，它必须设置明确的高度，否则内容超出部分不会产生滚动效果。
排查链路我一般这么走：
- 检查页面最外层是否设了
height: 100vh，如果设了，再看是否有overflow: hidden，有的话去掉； - 检查是否有
position: fixed遮罩层把整个页面覆盖住了，这会导致底部触摸事件被拦截； - 检查
scroll-view是否设置了enhanced属性和show-scrollbar，在某些iOS版本下不设会有诡异表现； - 真机上打开vConsole看有没有触摸事件报错。
热词里“苹果手机在微信小程序不能进行滑动滚动”这个现象，99%不是小程序本身的bug，而是页面布局问题。用page-meta设置page-style可以在页面级的滚动容器上做更精确控制。
4.2 单选框的取值与样式：比想象中更容易翻车
单选框在小程序里有radio组件和radio-group包装。最常见的翻车点是：radio-group的bindchange事件里取到的e.detail.value是选中的value值，而radio标签内部的value需要你自己设置，并且它要求唯一。如果你用数组的index做value值，当列表重新排序后，选中状态会错乱。
另一个坑是自定义单选框样式。原生radio默认有圆圈样式，定制起来很麻烦。我的建议是：如果只是简单表单，直接用原生组件；如果要做商品规格选择、头像勾选这类交互复杂的单选框，推荐用view+图标替代，不要硬刚原生样式。
4.3 图片长按：基础能力但权限敏感
微信小程序图片有一个常用属性show-menu-by-longpress，设为true后，用户长按图片会弹出菜单，可以识别二维码、转发给朋友、保存图片。这个能力很实用，但请注意：保存图片到相册需要用户授权scope.writePhotosAlbum。如果你不主动调用wx.saveImageToPhotosAlbum，长按菜单里的“保存图片”是微信自己控制的，不需要你额外处理授权。
如果做电商小程序，建议商品图都开启show-menu-by-longpress，提升转发和识别二维码的便利性。但如果图片里带二维码，微信识别后跳转的是外部链接，容易被判为诱导跳转，审核时要小心。
4.4 返回拦截：在小程序里能做到什么程度
热词里有“微信小程序 返回拦截”，这通常是想实现“用户点击左上角返回时，弹窗确认”或者“用户误触返回时停留在当前页”。原生小程序里，onUnload是页面销毁的时机，但它无法阻止用户返回。真正能拦截返回的是wx.enableAlertBeforeUnload（开启页面关闭确认弹窗）和wx.disableAlertBeforeUnload（关闭确认弹窗）。
Page({ onLoad() { wx.enableAlertBeforeUnload({ message: '内容尚未保存，确认离开吗？', success: () => { console.log('已开启拦截'); }, }); }, onUnload() { wx.disableAlertBeforeUnload(); }, });注意：这个拦截能力只对“返回上一页”“退出小程序”等场景生效，对通过wx.redirectTo跳转、差一个页面也不一定拦得住。另一个实现“手动返回拦截”的方法是自定义导航栏的返回按钮，接管返回事件，但这种方案会牺牲原生的过渡动画和右滑返回手势，我一般只在特殊场景（比如表单页、答题页）用。
5. 真机调试与发布：那些让人崩溃的疑难杂症
5.1 真机调试请求无法到达后端：排查顺序决定效率
“微信小程序真机调试请求无法到达后端”这个热词出现的频率超高。我把它当成一个标准的排障题来处理。你可能遇到的情况有：
- 开发者工具里请求正常，手机上一请求就报
fail url not in domain list； - 手机在开发者工具里打开了“不校验合法域名”，局域网请求成功，但真机预览就失败；
- 真机调试模式下wifi网络正常，但请求一直pending到超时。
排查顺序我建议这么走：
- 先看真机上是否勾选了“开发调试模式”，如果用的是预览版二维码，域名校验一定是强制的；
- 打开右上角“...”菜单 → 开发调试 → vConsole，看具体错误码；
- 如果是url not in domain list，去mp后台的“开发管理-开发设置-服务器域名”里把
request合法域名加上，注意必须HTTPS； - 如果域名已配置但请求仍是网络错误，用钉钉或者在线工具ping一下后端域名，确认证书链是否完整、是否被运营商拦截；
- 如果是局域网调试，检查手机和电脑是否在同一局域网，以及后端是否监听了电脑的局域网IP而不是只有127.0.0.1。
常见错误码与解决方案我整理过一张表，写代码时很有用：
| 错误提示 | 原因 | 解决办法 |
|---|---|---|
| url not in domain list | 域名未配置或不在合法列表中 | 后台添加request合法域名 |
| errno:600001 | 网络连接失败 | 检查手机网络、DNS、后端服务 |
| errno:600002 | URL非法 | 检查是否缺少https前缀 |
| errno:600003 | 请求超时 | 后端接口耗时过长或不可达 |
| errno:600004 | 请求过多 | 触发微信流量控制，稍后再试 |
5.2 HBuilderX发行微信小程序的超详细步骤
如果你是uni-app开发，最终发行到微信小程序的步骤对新人来说是一个容易翻车的地方。以下是完整流程：
- 在HBuilderX里打开项目，打开
manifest.json，选择“微信小程序”模块，填好AppID； - 点击菜单栏“运行” → “运行到小程序模拟器” → “微信开发者工具”，首次会要求配置微信开发者工具路径（找到微信web开发者工具.exe的位置），点击确定后会自动打开微信开发者工具加载项目；
- 如果只是在微信开发者工具里调试，到这一步就够了。要正式上传，点击“发行” → “小程序-微信”，HBuilderX会生成一个
unpackage/dist/dev/mp-weixin目录，同时自动打开微信开发者工具； - 在微信开发者工具里点击“上传”按钮，填写版本号和备注，代码就会上传到微信后台；
- 登录mp后台，在“版本管理”里找到刚上传的开发版本，提交审核并等待结果。
我自己遇到过的坑是：unity或原生小程序插件在小程序端不支持时，编译期不报错，但一上传就报component is not found。这时候要到微信开发者工具的“详情-本地设置”里打开“不校验合法域名、web-view（业务域名）、TLS版本以及HTTPS证书”，看具体报错组件名。另外，发行前一定要在HBuilderX里“重新编译”一次，不要直接使用旧的mp-weixin目录，否则会出现代码没更新的诡异问题。
5.3 反编译、抓包与技术围观：边界感要在线
热词里的“微信小程序反编译”“微信小程序抓包”在开发者圈子里一直是热门话题。说实话，前端代码包是能通过一些方式还原出源码结构的，这是所有前端技术的固有属性，小程序也不例外。但我要清清楚楚强调一句：反编译和抓包这些技术，如果你用来分析自己开发的小程序、排查线上问题，那是正当的技术手段；如果用来获取他人小程序的商业逻辑、绕过支付规则、下载付费视频、拉票刷量，那就突破了合规边界。微信平台对这类行为有成体系的处罚机制，轻则封禁接口，重则封号拉黑，甚至可能涉及法律纠纷。抓包调试的正确姿势是在自己的开发环境里，针对自己的接口、自己的后端进行联调，通过代理工具查看请求参数和响应数据，定位问题。至于“小程序视频怎么下载”这类需求，如果是你自己有版权的内容，不在小程序端提供下载能力时，你可以通过自己的接口实现导出；如果是别人的视频，那就是侵权行为了。
对于接外包、做项目的开发者，我还有一个额外提醒：不要把“绕过平台审核”“破解支付”“自动化抢单脚本”这类需求当作卖点接，这类项目短期来钱快，但不确定性极高，一旦平台策略升级，整个项目就是一颗定时炸弹。
6. 常见项目类型与AI辅助开发流程
6.1 典型项目拆解：校园跑腿服务平台
热词里“基于微信小程序的校园跑腿服务平台”是典型的实战项目，也是很多毕业生、接单开发者的热门选择。这个项目的核心价值可以拆成四个模块：
- 用户端：下单、支付、订单跟踪、取消订单、评价；
- 跑腿端：抢单、取件、送达、上传凭证；
- 管理后台：用户管理、订单管理、佣金结算、申诉处理；
- 基础能力：登录、定位、推送、地图轨迹。
看起来功能不复杂，但真正开发时最耗时间的是“订单状态机”。从待支付 → 待接单 → 已接单 → 已取件 → 配送中 → 已送达 → 已评价，每一步的状态变更都可能触发支付回调、微信通知、库存扣减等操作。如果状态流转没有严格校验，用户退款、跑腿员取消订单之类的情况会瞬间把数据一致性打崩。
技术上我会建议后端用Redis缓存当前热点订单的状态，避免高并发下重复请求导致重复派单；前端在“非当前状态”的按钮上做置灰处理，减少用户误触。这个项目的另一大坑是校园场景下的定位精度，宿舍楼宇内GPS信号差，需要引入“手动选择楼栋+楼内定位辅助”的交互设计。
6.2 景区票务与车位联动预约
“基于微信小程序景区票务与车位联动预约系统”是另一个高频项目。它的核心难点在于“联动”二字。票务系统和车位系统的余量是独立的，但如果用户预约了门票却没有预约车位，到达景区后可能没有停车位；反过来车位有余但门票售罄也会导致游客白跑一趟。
我的设计思路是：购票请求和后端对车位数做“预占”，支付成功后正式占用，超时未支付自动释放。车位预占和票务预占要写在同一个事务里，用分布式锁（如Redis lock）防止超卖。用户端界面将“门票+车位”做成一个套餐选项，用户选套餐后一起下单。前端看起来只是两个勾选框，但后端要处理的是两套库存的一致性。
项目还涉及订单超时回滚、退款时释放资源、节假日高峰流量削峰等细节。景区小程序的开发重点反而不在前端酷炫，而在数据一致性设计上。
6.3 大厂AI协助开发流程：提效是真实的，但不能无脑用
热词里“大厂ai 协助开发流程”很有意思。我现在开发小程序，AI确实承担了不少“翻译、查文档、补胶水代码”的活。典型的协作流程是：
- 我先在需求文档里把页面流转、字段、接口定义写清楚；
- 用AI生成骨架代码：页面结构、静态布局、工具函数、组件封装；
- AI生成的代码我会逐行审查，重点看：输入校验、异常处理、状态管理、权限判断；
- 用AI做代码解读和bug定位辅助，比如把报错堆栈贴给AI，让它给排查方向；
- 最后的人工环节是测试与真机适配。
我给的提示词一般会带上“小程序原生/uni-app、微信开发者工具、版本兼容范围、禁止使用不存在的API、参数需要判空”这类约束条件，出来的代码质量会高很多。一个可复用的示例：
请帮我用 uni-app 写一个订单确认页，包含商品列表、 配送地址、订单金额、提交订单按钮。 要求： 1. 使用 Vue3 setup 语法； 2. 表单提交前做必填校验； 3. 接口请求统一走 utils/request.js； 4. 处理 loading 状态和错误提示； 5. 适配 iPhone 底部安全区。我踩过的坑是AI生成了一些微信开发者工具里根本不存在的高版本API，比如早期版本不支持的方法名，或者把浏览器的localStorage直接写进小程序里。所以AI生成的代码，replace动作必须人工复核，这是底线。在小程序中，存储用wx.setStorageSync，请求得带上header token，这些上下文信息AI经常漏，你在提示词里补全它才能输出更好的结果。
另外，AI最适合干“项目脚手架”“接口层封装”“重复性报表页面”这类弱业务逻辑代码，不要指望它替你设计复杂的业务状态或处理审核合规问题。这些事永远需要真正理解平台规则的人来把关。
7. 开发完成后的运营视角：审核、发布与迭代
代码写完只是开始，上线后的审核才是很多团队第一次真正见识“微信规则”的地方。提审前我建议你自查这几点：
- 启动页、首页不得含有二维码引导下载App或跳转其他平台；
- 如果涉及会员、VIP等付费，iOS端必须走IAP或屏蔽，否则审核驳回率极高；
- 用户隐私协议必须选择并配置在后台，且实际生效——微信会抽查；
- 类目选择要准确，比如电商不能选“工具”，否则功能审核不通过；
- 每次提交说明里写清楚本次更新了什么，尤其是涉及支付、隐私、位置权限变更时，说明越详细过审越快。
发布后重点关注的是用户反馈渠道。小程序没有开放评论功能，但你可以在“设置-基本设置-服务类目”里配置客服消息。客服消息可以在用户关注公众号或打开小程序时触发，建议用微信云开发或后端接口承接自动回复，至少要解决“人工接待前仍有响应”的基础体验。
迭代节奏上，每次发版前在开发者工具里跑一遍“体验评分”（右上角“详情-体验评分”），低于80分的项目慎重发布。微信的评分指标会告诉你哪些环节存在卡顿、白屏、请求慢的问题，比你自己凭感觉排查高效得多。
还有一个容易被忽略的运营细节：小程序的分享卡片。onShareAppMessage返回的title、path、imageUrl如果配置得足够好，会直接影响用户分享出去的打开率。很多开发者把分享功能当摆设，其实它在获客拉新上的价值远比付费投流来得划算。
做小程序的几年里，我最大的感受是：这个平台表面上是“一套前端技术栈”，实际上链接着账号体系、支付合规、内容审核、设备权限、跨端适配这一大堆规则。写得越快，越要在平台规则里多花时间琢磨。毕竟代码可以让你跑起来，规则才决定你能不能活下来。
