做外卖类小程序这几年前前后后经手过不少项目从单店点餐到多商家平台都碰过。最近整理代码仓库翻到之前团队那个外卖商城小程序的完整工程内部代号叫weixin129——这个编号其实没什么特殊含义就是当时内部用来追踪迭代版本随手起的但回过头看从0到1把一个微信小程序外卖商城跑通里面涉及的东西远比想象中多。这篇文章就把这套项目的完整链路拆开讲一遍从整体设计到技术选型再到支付、定位、真机调试这些绕不过去的坑适合正在学小程序开发、或者准备接外卖/O2O商城类需求的朋友参考。如果你已经有了一些小程序基础可以直接跳到第3章看核心模块的实现细节如果你是刚入门建议从头到尾顺着读我把项目里很多“当初没想明白、后来踩了坑才懂”的地方也都写了进去。1. 项目整体拆解weixin129到底做了什么1.1 外卖商城小程序的核心业务链路外卖商城类的微信小程序本质上是一个三端联动的交易平台用户端负责浏览和下单商家端处理接单和出餐平台管理后台则承担商品、订单、结算和运营配置。weixin129这个项目在最初的MVP版本里做了完整的用户端商家端先用管理后台代替订单通过后台分配给商家处理。用户端的核心页面和功能闭环是这样的首页根据用户定位展示附近商家按销量、评分、距离排序支持搜索商家和菜品。点餐页商家主页内有分类菜单、菜品SKU规格如大份/小份、加辣/微辣、购物车联动、菜品评价列表。确认订单页选择收货地址、配送时间、备注计算配送费和优惠券抵扣。支付对接微信支付完成统一下单、支付回调、订单状态流转。订单中心待支付、待接单、配送中、已完成、退款/售后等状态分组展示。个人中心用户信息、收货地址管理、优惠券、客服与设置。这整套流程看起来是标准的电商闭环但外卖场景里有两个非常特殊的点LBS强依赖和订单时效性。用户打开小程序第一眼看到的就是“附近有哪些店”而不是“全部商品”所以首页的信息结构必须围绕地理位置来设计订单一旦支付成功商家必须在几分钟内接单否则体验就会崩这对消息推送和订单状态同步的要求很高。1.2 为什么这类项目选微信小程序而不是App或H5这个决策在weixin129立项时其实讨论过一轮。外卖是一个高频、强交易场景但它的用户触点往往来自“临时需求”——比如中午不知道吃什么、朋友群里分享了一家店。这种场景下App的下载成本太高H5 的支付体验和系统能力又不够。微信小程序在这类项目里有几个天然优势即用即走获客成本低小程序通过好友分享、微信群卡片、附近的小程序入口就能触达用户不需要跳转应用商店。支付闭环顺畅微信支付在 WebView 里调用需要 JS-SDK 配置域名而且有被拦截的风险小程序里直接wx.requestPayment安全性和成功率都高很多。LBS 能力内置wx.getLocation配合腾讯位置服务不需要自己维护复杂的地图 SDK 兼容问题。订阅消息触达订单状态变更可以通过订阅消息推送给用户不需要自建推送通道。缺点当然也存在最明显的是包体大小限制主包 2MB通过分包最多到 20MB 左右和审核约束。外卖类目还需要提供《食品经营许可证》等资质这是很多开发者前期容易忽略的点。1.3 这套项目适合谁来参考如果你是以下三类人weixin129的拆解思路会很有用正在学微信小程序开发的初学者跟着核心模块走一遍能理解一个真实交易类小程序是怎么组织代码和设计状态的而不是停留在写个 Todo List 的层面。准备接外卖/O2O商城类外包或自研的技术人员项目里的技术选型对比、支付流程、地图接入方案可以直接复用。需要和 Java 后端配合的前端开发者我在后面详细写了自定义登录鉴权、支付回调这类前后端交互细节能帮你避免很多联调时的返工。2. 技术选型前端、后端与工程结构怎么定2.1 小程序前端原生还是 uni-app/Taro这是立项时的第一个岔路口。现在社区里跨端框架已经很成熟了uni-app和Taro都能一套代码编译到微信小程序、H5、App听起来很诱人。但就外卖商城这类深度依赖微信生态能力的项目我当时在weixin129里最终还是选择了原生小程序 少量自定义组件的方案。原因主要有三个微信原生 API 的坑最少。原生开发时wx.getLocation、wx.requestPayment、wx.chooseAddress这些高频能力直接调用就行换成跨端框架后总有一些封装层来不及同步新能力遇到问题还得去翻框架源码。性能和包体更好控制。外卖小程序的商家列表、订单列表数据量不小原生框架在长列表渲染上更可控分包加载、独立分包这些优化手段原生配置起来也最直接。团队协作成本。项目里大部分成员都有小程序原生开发经验用原生可以避免引入框架自身的版本升级和维护成本。但这不代表跨端方案就不好。如果你们团队本来就以 Vue/React 技术栈为主且有明确的App端发布需求uni-app或Taro也完全可行。weixin129的取舍只说明了一个道理技术选型要考虑团队熟悉的武器和项目真正的战场。2.2 后端技术栈与数据存储后端采用Java Spring Boot MySQL Redis这套经典组合。没有选择云开发主要是考虑到项目后续要接第三方的商家管理后台和数据分析系统后端接口需要提供给多端复用自建后端在灵活性和扩展性上更好。MySQL 里这 6 张核心表撑起了整个外卖业务表名核心字段说明useropenid、昵称、手机号、默认地址IDshop店名、经纬度、起送价、配送费、营业状态dish所属店铺ID、菜品名、图片、价格、SKU属性cart用户ID、店铺ID、菜品ID、数量、规格快照orders订单号、用户ID、店铺ID、金额、支付状态、配送状态order_item订单号、菜品ID、数量、下单时价格快照Redis 缓存了高频读取的数据比如商家列表、菜品详情、用户 token。当初为了简化直接用了 Mysql 的经纬度字段配合 Haversine 公式计算距离来做商家排序数据量小的时候性能没问题。如果商家规模做到上千家建议尽早引入 Elasticsearch 的 geo_distance 查询或者用 Redis GEO。2.3 开发工具与环境准备weixin129的日常开发工具链如下微信开发者工具写原生小程序代码、预览、真机调试、上传代码都用它。建议开启“自动保存编译”和“热重载”能省不少时间。VS Code用来写后端 Java 代码和部分前端公共逻辑配合 Git 做版本管理。HBuilderX如果你们用 uni-app这个工具链会更顺。不过我上面说了本项目没走这条路。开发准备阶段有几个非常关键的步骤新手容易卡住在 微信公众平台 注册小程序账号完成企业主体认证外卖类目必须有企业资质个人主体无法申请支付和外卖类目。获取 AppID而不是用测试号。测试号没有支付权限很多能力调不通。在「开发管理 - 开发设置」里配置request 合法域名、socket 合法域名、uploadFile 合法域名。开发阶段可以勾选“不校验合法域名”但上线前必须全部配置成 HTTPS 域名。下载微信开发者工具用 AppID 登录导入项目。注意支付功能需要先开通微信支付商户号并完成商户号和小程序的绑定。个人开发者无法申请支付个体户也面临一定限制这个商务流程要提前走否则开发完了才发现支付资质没下来项目只能干等着。3. 核心功能模块的实现拆解3.1 微信登录与用户体系构建几乎所有微信小程序的用户体系都是以wx.login为起点的。流程是这样的小程序端调用wx.login拿到一个临时code把code发给自己的后端后端拿着code调用微信的code2Session接口换取openid和session_key之后以openid作为用户唯一标识。weixin129里我在这个基础上加了 token 鉴权机制而不是每次请求都拿着 code 去微信换 openid那样效率太低// 后端伪代码登录接口 public Result login(String code) { // 1. 用 code 向微信服务端换取 openid MapString, String session wxService.code2Session(code); String openid session.get(openid); // 2. 查数据库不存在则创建用户 User user userMapper.selectByOpenid(openid); if (user null) { user new User(); user.setOpenid(openid); userMapper.insert(user); } // 3. 生成自定义 token 并缓存到 Redis String token UUID.randomUUID().toString().replace(-, ); redisTemplate.opsForValue().set(token: token, String.valueOf(user.getId()), 7, TimeUnit.DAYS); return Result.ok(token); }小程序端拿到 token 后存储在本地每次请求在 header 里带上Authorization: token。后端通过拦截器统一校验没有 token 或 token 过期就直接返回 401前端拦截到 401 后自动跳转登录页。手机号授权这块现在微信的规则是必须通过getPhoneNumber按钮组件触发不能直接调 API 获取。而且企业主体的小程序才能申请该能力个人主体不行。这里有个经验千万别把手机号作为用户是否登录的判断依据很多用户会拒绝授权手机号但他们仍然可以浏览和加购只是下单的时候才强制要求填写收货地址。3.2 点餐与购物车本地缓存还是服务端存储购物车在weixin129里是一个反复改过的模块。最初的版本做得比较“重”——用户每点一次加购前端都调接口去服务端存购物车数据理由是防止用户换手机或者清缓存后购物车丢失。但实际用下来发现这个方案有严重的问题接口压力大点一个菜品就是一次 HTTP 请求高峰期频繁点菜时体验会变差。购物车状态一致性难处理用户在 A 店加购了 5 道菜又跑到 B 店加购购物车里的店铺维度归并逻辑在后端实现起来很绕。最终版本改成了混合策略购物车数据主要存储在小程序本地Storage里结构大概长这样// 本地购物车结构 const CART_KEY cart; // 存储结构以 shopId 为维度分店存 // cartMap: { [shopId]: [{ dishId, name, price, spec, count }] }每次加购、修改数量、删除菜品只更新本地 Storage同时在页面切换时用wx.setStorageSync直接落盘。用户进入确认订单页的时候才把本地购物车数据一次性提交给后端由后端生成订单草稿后续支付成功后清理本地购物车。这个方案的优点是前端交互流畅、接口压力小缺点是用户换设备后购物车确实会丢但对大多数外卖场景来说可以接受。如果你要做“真正多端打通”的购物车建议用服务端存储但要把店铺维度的合并逻辑想清楚。wx.setStorageSync单个 key 的存储上限是 1MBweixin129里购物车数据从来没有超过这个上限所以本地存储完全够用。我还加了一个“存储超限自动清理最旧记录”的兜底逻辑防止异常情况下 Storage 写不进去导致白屏。3.3 微信支付的核心流程与参数细节微信支付是外卖小程序的重中之重也是最容易出问题的环节。weixin129走的是JSAPI 支付核心链路如下小程序端提交订单后端生成订单号并返回给小程序端。小程序端拿到订单号后调自己的后端接口/pay/create后端在微信支付服务端生成预支付单prepay_id。后端将签名后的支付参数返回给小程序端。小程序端调用wx.requestPayment拉起收银台用户输入密码完成支付。微信后台异步通知后端回调接口/pay/notify后端校验签名、更新订单状态、返回 XML 给微信确认接收。有一个很多新手会踩的坑wx.requestPayment里需要传入的paySign并不是直接用商户 API 密钥去签名而是要用商户号、随机串、时间戳、prepay_id 等按固定格式拼接后再用 MD5 或 HMAC-SHA256 签名。官方文档的说法比较抽象我直接贴一个签名前的原始字符串格式appIdwx1234567890abcdef nonceStr5K8264ILTKCH16CQ2502SI8ZNMTM67VS packageprepay_idwx201410272009395522657a690389285100 signTypeMD5 timeStamp1414485394这串字符串按照keyvalue格式用连接结尾加上商户密钥再做 MD5最终得到paySign。顺序不能乱少了任何一项都会签名失败。还有一个容易踩的坑支付回调地址必须是公网 HTTPS 地址并且处理完业务逻辑后一定要向微信返回成功报文{code:SUCCESS}。如果不返回微信会连续多次通知直到超时。我在开发环境里用内网穿透工具把本地服务映射出去接收回调调试效率高很多。但要注意内网穿透工具只适合开发阶段上线前一定要换成正式公网网关。3.4 苹果手机虚拟支付的合规性处理做外卖商城这类实物交易走的还是微信支付-JSAPI不涉及虚拟支付。但如果项目里混入了会员充值、金币购买、付费解锁功能等虚拟商品就需要格外注意苹果的政策虚拟商品在小程序里不能使用微信支付必须走苹果 IAP否则会面临审核被拒甚至下架。weixin129在某些版本里尝试过“会员月卡”这类虚拟权益审核时被提示“含虚拟支付内容需要接入苹果 IAP 或移除该功能”。当时为了合规省事直接把虚拟商品功能从微信小程序端移除改成了 H5 网页端购买。如果你确实需要在微信小程序里做虚拟商品比较稳妥的路径是虚拟商品功能部署在 H5 页面通过web-view嵌入。H5 端对接苹果 IAP 支付或使用第三方支付平台提供的 H5 支付方案。小程序端不给虚拟商品提供入口避免触碰审核红线。因为 IAP 支付涉及到与苹果 30% 抽成之后的结算流程加上退款周期长、用户体验复杂很多团队在微信小程序里干脆不做虚拟支付。这个决定虽然损失了一部分营收但省下来的审核沟通成本和安全风险是值得的。3.5 地图定位、web-view 与文件下载的常见处理外卖项目里地图定位几乎是标配。weixin129使用了腾讯位置服务微信小程序内置支持不需要额外下载地图 SDK。核心步骤在腾讯位置服务控制台创建应用获取 key。小程序端调用wx.getLocation获取经纬度。调用腾讯位置服务 WebService API 做逆地址解析把经纬度转成中文地址展示。wx.getLocation({ type: gcj02, success(res) { const { latitude, longitude } res; // 调腾讯逆地址解析 wx.request({ url: https://apis.map.qq.com/ws/geocoder/v1/?location${latitude},${longitude}keyYOUR_KEY, success(addressRes) { const address addressRes.data.result.address; console.log(address); } }); } });注意wx.getLocation需要在app.json里声明permission字段并且要申请开通“位置信息”接口权限否则调用会失败{ permission: { scope.userLocation: { desc: 您的位置信息将用于展示附近的商家 } } }对于web-view组件外卖小程序的商家公告、隐私政策、富文本活动页都可以用 H5 承载。常见的问题是web-view高度只有屏幕高度没有自适应内容。实际上web-view组件天生就是全屏的里面网页自己内部滚动不存在“改高度”这个操作。需要做的是在 H5 网页内部适配好滚动和尺寸外层小程序页面直接全屏盖住即可。关于视频和图片下载平时做活动页时经常需要在小程序里提供视频预览或海报保存。视频下载在小程序里不能直接完成最合规也最推荐的方式是在视频页提供“复制链接 用户自己到浏览器下载”的引导如果非要做小程序内下载需要用到wx.downloadFile配合wx.saveVideoToPhotosAlbum但前提是视频文件支持 Range 请求并且格式正确。图片长按保存则更简单image组件天然支持长按识别和保存只要没有打开show-menu-by-longpress的禁用开关。3.6 iOS 静音模式下播放音乐的坑外卖小程序支付成功后的提示音、取餐叫号提示音这些场景经常会遇到一个诡异问题安卓手机上声音正常iPhone 只要开了静音就完全没声音。原因是 iOS 上 WebView 和小程序的音频播放默认遵循静音键状态而安卓默认不跟随。微信小程序的解决方式是通过InnerAudioContext设置const innerAudioContext wx.createInnerAudioContext(); innerAudioContext.src https://your-domain.com/audio/notify.mp3; innerAudioContext.obeyMuteSwitch false; // iOS 下忽略静音键 innerAudioContext.play();obeyMuteSwitch默认值是true跟随静音键设置为false之后即使 iPhone 静音键开启也能正常播放音乐。这个属性只在 iOS 上生效安卓端配置了也不会有什么副作用。我当时排查这个问题花了半天时间在真机上反复测试最后发现就是文档角落里的一句话没注意。另外InnerAudioContext播放音频有并发限制如果同时创建多个实例会互相打断。更好的做法是在页面里只创建一个全局音频实例播放前先stop()再play()。4. 真机调试、抓包与常见问题排查实录4.1 真机调试请求无法到达后端开发阶段最头大的问题就是开发者工具里一切正常一上真机所有接口全部失败。weixin129初期也遇到过而且报错信息还各不相同有的直接 timeout有的提示 “url not in domain list”。排查思路按下面几步走基本能定位到问题确认基础库版本微信开发者工具更新后基础库版本和手机上的版本可能不一致低版本基础库对某些 API 支持不完整。在开发者工具右上角可以切换基础库版本尽量用高于线上最低版本的库。确认HTTPS证书完整小程序真机环境强制要求 HTTPS 且证书链完整。在一些免费证书平台申请的证书有时候中间证书缺失浏览器访问没问题但小程序真机会直接报错。确认域名白名单真机环境下非白名单域名请求会被拦截。开发阶段可以暂时勾选“不校验合法域名”但这样只能调试不能预览和发布。正确做法是先把开发环境的域名比如dev-api.yourdomain.com提前配到白名单里。确认局域网IP可达如果你直接连电脑的局域网 IP 调试要注意手机和电脑必须在同一个 WiFi 下且防火墙没有拦截端口。我经常遇到公司电脑防火墙开着导致手机访问不到的情况关闭或放行相关端口后问题就解决了。4.2 iOS 机型网络请求失败率高错误6001异常有段时间weixin129的 iOS 用户反馈支付和下单页面网络请求失败的频率明显高于安卓后台日志里出现了大量的6001错误。查了一圈发现这其实是 iOS WebView 对网络连接的一个限制问题同时发起的并发请求过多时部分请求会被挂起或直接失败。原因在于小程序页面数据加载时如果没做“请求合并”或“请求递归控制”容易出现一次性发出十几个请求的情况。尤其是一个页面组件多、每个组件各自拉接口时最容易触发 iOS 的并发限制。解决办法是并发控制全局封装一个请求管理器给同一时间最多允许发起的请求数设上限比如 5 个超出部分排队等待。页面级数据聚合把商家信息、菜品列表、评价数据合并到一个聚合接口里减少请求数。失败重试机制对 GET 类数据请求增加指数退避重试逻辑第一次失败后隔 2 秒重试再失败隔 4 秒重试最多重试 3 次。这样能有效消化瞬时网络抖动。6001 这个错误码在微信官方文档里没有很详细的解释但结合社区经验大多数时候跟网络连接失败/超时有关按上面的方向处理基本都能缓解。4.3 抓包定位接口问题Fiddler/Charles 实战思路联调阶段经常需要抓包看小程序发出了什么请求、后端返回了什么数据。weixin129里我用的是 Fiddler 抓包。说是“小程序抓包”原理其实不复杂让手机 WiFi 代理指向电脑上的 Fiddler再由 Fiddler 解密 HTTPS 流量。操作步骤大致是这样的电脑和手机连同一个 WiFi。Fiddler 设置允许远程连接Tools → Options → Connections → 勾选 Allow remote computers to connect。Fiddler 开启 HTTPS 解密HTTPS 选项卡 → 勾选 Decrypt HTTPS traffic。手机 WiFi 设置 HTTP 代理为电脑局域网 IP端口填 8888。手机浏览器访问http://电脑IP:8888安装 Fiddler 生成的根证书。再打开微信小程序请求就会在 Fiddler 里被捕获到。这里有个坑安装了根证书之后部分 Android 手机上的微信小程序依然抓不到包这是因为 Android 7.0 以上默认不信任用户安装的 CA 证书。想要彻底解决需要手机 Root 后把证书放到系统目录或者找一台旧版的 Android 测试机。用 iOS 设备配合 Fiddler 能省很多事我一般准备一台专门的测试 iPhone 用来抓包。抓包能帮我们干很多事比如确认请求头是否带上了 token、实际请求的 URL 和开发者工具里是否一致、后端返回的数据结构到底是哪种格式。有时候前后端联调半天对不上打开抓包一看原来是前端请求发错了路径。4.4 返回拦截与自定义导航栏适配外卖小程序的点餐链路比较长首页→商家列表→商家主页→菜品详情→确认订单。用户习惯性地点击左上角返回键有时候希望回到上一级有时候又希望直接跳到首页。weixin129里做了一套“返回拦截”逻辑用来自定义返回行为。微信小程序原生提供的onUnload生命周期函数无法拦截返回操作想拦截必须用自定义导航栏方案然后在返回按钮上做处理// 自定义导航栏返回点击 navigateBack() { const pages getCurrentPages(); if (pages.length 1) { wx.navigateBack({ delta: 1 }); } else { wx.switchTab({ url: /pages/home/home }); } }之所以要判断pages.length是因为如果用户从某个分享卡片直接进入小程序页面栈里可能只有当前这一个页面这时候调用navigateBack会失败需要退回到首页。自定义导航栏还涉及一个基础问题顶部导航栏高度适配。不同手机的胶囊按钮位置不一样计算方法是// 获取菜单按钮胶囊的位置信息 const menuButton wx.getMenuButtonBoundingClientRect(); // 状态栏高度 const statusBarHeight wx.getSystemInfoSync().statusBarHeight; // 导航栏内容高度通常用胶囊按钮的 top 减去状态栏高度再加上胶囊高度与上下间距的估算这套计算逻辑在weixin129里被封装成了一个工具函数所有要用自定义导航栏的页面统一调用保证不同机型上标题文字都能垂直居中、不被胶囊遮挡。4.5 常见问题速查表整理一份weixin129开发过程中遇到的高频问题直接对照着看问题描述常见原因解决方案真机请求全部 timeout域名未加白名单 / HTTPS 证书链不完整配置合法域名、修复证书链iOS 支付后不回调回调地址内网不可达 / 回调返回格式不对配置公网回调处理完返回 SUCCESS播放提示音无声iOSobeyMuteSwitch默认跟随静音键设为false页面被胶囊按钮遮挡未适配状态栏/胶囊高度用wx.getMenuButtonBoundingClientRect计算web-view 空白业务域名未配置小程序后台添加业务域名定位失败/城市错误坐标系不一致 / 未声明 permission统一用 gcj02声明scope.userLocation图片长按无反应未开启show-menu-by-longpressimage组件加上该属性视频下载到相册失败未处理相册权限 / 文件格式问题用wx.saveVideoToPhotosAlbum前先授权5. 上线审核、性能优化与后续扩展思考5.1 外卖类小程序审核的材料与注意事项外卖类目的小程序在微信审核时比较严格weixin129第一次提审就被打回了一次主要是类目资质问题。你要在「小程序后台 - 设置 - 服务类目」里找到“餐饮 外卖/订餐”这一项然后提交《食品经营许可证》。如果你的平台是给别人做外卖配送的还需要提供《增值电信业务经营许可证》ICP 证或相关备案这个门槛让很多小团队在平台化路线上吃了不少苦头。审核注意事项里有几个点必须提前处理隐私政策必须有且内容完整。现在微信对用户隐私保护要求很高小程序内必须提供隐私政策页面说明收集了哪些信息、用途是什么。虚拟支付内容绝对不能有。一旦出现在苹果手机上不能支付的虚拟商品页面大概率会被拦。违规口令和诱导分享词不要出现。外卖活动页经常有“分享到群才能领优惠券”这类设计这类诱导分享在微信生态里是违规的审核不会通过上线后也可能被处罚。5.2 性能优化分包加载、图片压缩与骨架屏外卖小程序页面多、图片多稍微不注意就变成“打开慢、滑动卡”的重灾区。分包加载把商家入驻、订单详情、售后页面这些不常用模块拆进分包里主包保持越小越好。weixin129里把“商家入驻”、“客服聊天”、“发票抬头设置”这些低频页面都放进了分包主包体积从 1.8MB 降到了 1.2MB启动速度明显提升。图片压缩与 CDN菜品图必须做压缩推荐 WebP 格式尺寸按最大展示宽度的两倍生成。开发阶段直接用原图很容易让列表页内存爆炸在 iOS 上尤其明显。骨架屏首页和商家列表这类数据页面在上拉加载时展示骨架屏能大幅降低用户的“白屏焦虑感”。微信原生支持page-meta里的下拉动画自定义配合骨架屏的效果更自然。5.3 后续还能往哪些方向扩展跑通weixin129的基础交易闭环后后续扩展方向其实很清晰一是商家端的独立 App 或小程序把接单、出餐、配送管理从人工后台操作变成移动端作业商家更愿意用骑手也能及时收到取餐通知。二是预约类功能比如类似景区票务预约、校园跑腿这类场景。我做过的预约系统基本就是复用订单模块把“下单”改成“预约档期”把“配送地址”改成“服务地点”再加上日期选择和库存扣减模式是相通的。三是基于用户行为的推荐算法。外卖的复购率很高积累一定订单量后给用户推荐“常点商家的新菜品”“附近评分高的同类店”对转化率的提升非常明显。可以先从规则推荐做起比如“你最近一周点了 3 次川菜附近这几家川菜店评分都高于 4.5”逐步再上模型。四是一个容易忽略但很重要的点售后和客服系统。外卖和纯电商比餐品质量问题时效性要求极高用户反馈必须及时响应否则差评和投诉会直接影响商家评分和平台口碑。微信小程序接入wx.openCustomerServiceChat可以直接拉起微信客服比自建 IM 省事得多。最后再分享一个我做外卖小程序时印象很深的小技巧开发阶段在微信开发者工具的“本地设置”里开启“自动预览”配合一个测试用的童颜相机这个技巧其实没什么用我删掉了——说正经的我能给的最实在的建议是外卖小程序这类交易型项目功能上线只是第一步真正花时间的往往在支付回调、真机兼容、审核资质这些边角料环节。weixin129跑完整个流程我最大的体会就是不管框架多花哨把微信支付、用户鉴权、订单状态流转这三条主链路扎扎实实走通项目就已经成功了八成。如果你也在做类似的项目建议先把这三条链路的数据流图画清楚再开始撸代码能少走很多弯路。 外卖小程序开发实战：从微信支付到真机调试全链路拆解
做外卖类小程序这几年前前后后经手过不少项目从单店点餐到多商家平台都碰过。最近整理代码仓库翻到之前团队那个外卖商城小程序的完整工程内部代号叫weixin129——这个编号其实没什么特殊含义就是当时内部用来追踪迭代版本随手起的但回过头看从0到1把一个微信小程序外卖商城跑通里面涉及的东西远比想象中多。这篇文章就把这套项目的完整链路拆开讲一遍从整体设计到技术选型再到支付、定位、真机调试这些绕不过去的坑适合正在学小程序开发、或者准备接外卖/O2O商城类需求的朋友参考。如果你已经有了一些小程序基础可以直接跳到第3章看核心模块的实现细节如果你是刚入门建议从头到尾顺着读我把项目里很多“当初没想明白、后来踩了坑才懂”的地方也都写了进去。1. 项目整体拆解weixin129到底做了什么1.1 外卖商城小程序的核心业务链路外卖商城类的微信小程序本质上是一个三端联动的交易平台用户端负责浏览和下单商家端处理接单和出餐平台管理后台则承担商品、订单、结算和运营配置。weixin129这个项目在最初的MVP版本里做了完整的用户端商家端先用管理后台代替订单通过后台分配给商家处理。用户端的核心页面和功能闭环是这样的首页根据用户定位展示附近商家按销量、评分、距离排序支持搜索商家和菜品。点餐页商家主页内有分类菜单、菜品SKU规格如大份/小份、加辣/微辣、购物车联动、菜品评价列表。确认订单页选择收货地址、配送时间、备注计算配送费和优惠券抵扣。支付对接微信支付完成统一下单、支付回调、订单状态流转。订单中心待支付、待接单、配送中、已完成、退款/售后等状态分组展示。个人中心用户信息、收货地址管理、优惠券、客服与设置。这整套流程看起来是标准的电商闭环但外卖场景里有两个非常特殊的点LBS强依赖和订单时效性。用户打开小程序第一眼看到的就是“附近有哪些店”而不是“全部商品”所以首页的信息结构必须围绕地理位置来设计订单一旦支付成功商家必须在几分钟内接单否则体验就会崩这对消息推送和订单状态同步的要求很高。1.2 为什么这类项目选微信小程序而不是App或H5这个决策在weixin129立项时其实讨论过一轮。外卖是一个高频、强交易场景但它的用户触点往往来自“临时需求”——比如中午不知道吃什么、朋友群里分享了一家店。这种场景下App的下载成本太高H5 的支付体验和系统能力又不够。微信小程序在这类项目里有几个天然优势即用即走获客成本低小程序通过好友分享、微信群卡片、附近的小程序入口就能触达用户不需要跳转应用商店。支付闭环顺畅微信支付在 WebView 里调用需要 JS-SDK 配置域名而且有被拦截的风险小程序里直接wx.requestPayment安全性和成功率都高很多。LBS 能力内置wx.getLocation配合腾讯位置服务不需要自己维护复杂的地图 SDK 兼容问题。订阅消息触达订单状态变更可以通过订阅消息推送给用户不需要自建推送通道。缺点当然也存在最明显的是包体大小限制主包 2MB通过分包最多到 20MB 左右和审核约束。外卖类目还需要提供《食品经营许可证》等资质这是很多开发者前期容易忽略的点。1.3 这套项目适合谁来参考如果你是以下三类人weixin129的拆解思路会很有用正在学微信小程序开发的初学者跟着核心模块走一遍能理解一个真实交易类小程序是怎么组织代码和设计状态的而不是停留在写个 Todo List 的层面。准备接外卖/O2O商城类外包或自研的技术人员项目里的技术选型对比、支付流程、地图接入方案可以直接复用。需要和 Java 后端配合的前端开发者我在后面详细写了自定义登录鉴权、支付回调这类前后端交互细节能帮你避免很多联调时的返工。2. 技术选型前端、后端与工程结构怎么定2.1 小程序前端原生还是 uni-app/Taro这是立项时的第一个岔路口。现在社区里跨端框架已经很成熟了uni-app和Taro都能一套代码编译到微信小程序、H5、App听起来很诱人。但就外卖商城这类深度依赖微信生态能力的项目我当时在weixin129里最终还是选择了原生小程序 少量自定义组件的方案。原因主要有三个微信原生 API 的坑最少。原生开发时wx.getLocation、wx.requestPayment、wx.chooseAddress这些高频能力直接调用就行换成跨端框架后总有一些封装层来不及同步新能力遇到问题还得去翻框架源码。性能和包体更好控制。外卖小程序的商家列表、订单列表数据量不小原生框架在长列表渲染上更可控分包加载、独立分包这些优化手段原生配置起来也最直接。团队协作成本。项目里大部分成员都有小程序原生开发经验用原生可以避免引入框架自身的版本升级和维护成本。但这不代表跨端方案就不好。如果你们团队本来就以 Vue/React 技术栈为主且有明确的App端发布需求uni-app或Taro也完全可行。weixin129的取舍只说明了一个道理技术选型要考虑团队熟悉的武器和项目真正的战场。2.2 后端技术栈与数据存储后端采用Java Spring Boot MySQL Redis这套经典组合。没有选择云开发主要是考虑到项目后续要接第三方的商家管理后台和数据分析系统后端接口需要提供给多端复用自建后端在灵活性和扩展性上更好。MySQL 里这 6 张核心表撑起了整个外卖业务表名核心字段说明useropenid、昵称、手机号、默认地址IDshop店名、经纬度、起送价、配送费、营业状态dish所属店铺ID、菜品名、图片、价格、SKU属性cart用户ID、店铺ID、菜品ID、数量、规格快照orders订单号、用户ID、店铺ID、金额、支付状态、配送状态order_item订单号、菜品ID、数量、下单时价格快照Redis 缓存了高频读取的数据比如商家列表、菜品详情、用户 token。当初为了简化直接用了 Mysql 的经纬度字段配合 Haversine 公式计算距离来做商家排序数据量小的时候性能没问题。如果商家规模做到上千家建议尽早引入 Elasticsearch 的 geo_distance 查询或者用 Redis GEO。2.3 开发工具与环境准备weixin129的日常开发工具链如下微信开发者工具写原生小程序代码、预览、真机调试、上传代码都用它。建议开启“自动保存编译”和“热重载”能省不少时间。VS Code用来写后端 Java 代码和部分前端公共逻辑配合 Git 做版本管理。HBuilderX如果你们用 uni-app这个工具链会更顺。不过我上面说了本项目没走这条路。开发准备阶段有几个非常关键的步骤新手容易卡住在 微信公众平台 注册小程序账号完成企业主体认证外卖类目必须有企业资质个人主体无法申请支付和外卖类目。获取 AppID而不是用测试号。测试号没有支付权限很多能力调不通。在「开发管理 - 开发设置」里配置request 合法域名、socket 合法域名、uploadFile 合法域名。开发阶段可以勾选“不校验合法域名”但上线前必须全部配置成 HTTPS 域名。下载微信开发者工具用 AppID 登录导入项目。注意支付功能需要先开通微信支付商户号并完成商户号和小程序的绑定。个人开发者无法申请支付个体户也面临一定限制这个商务流程要提前走否则开发完了才发现支付资质没下来项目只能干等着。3. 核心功能模块的实现拆解3.1 微信登录与用户体系构建几乎所有微信小程序的用户体系都是以wx.login为起点的。流程是这样的小程序端调用wx.login拿到一个临时code把code发给自己的后端后端拿着code调用微信的code2Session接口换取openid和session_key之后以openid作为用户唯一标识。weixin129里我在这个基础上加了 token 鉴权机制而不是每次请求都拿着 code 去微信换 openid那样效率太低// 后端伪代码登录接口 public Result login(String code) { // 1. 用 code 向微信服务端换取 openid MapString, String session wxService.code2Session(code); String openid session.get(openid); // 2. 查数据库不存在则创建用户 User user userMapper.selectByOpenid(openid); if (user null) { user new User(); user.setOpenid(openid); userMapper.insert(user); } // 3. 生成自定义 token 并缓存到 Redis String token UUID.randomUUID().toString().replace(-, ); redisTemplate.opsForValue().set(token: token, String.valueOf(user.getId()), 7, TimeUnit.DAYS); return Result.ok(token); }小程序端拿到 token 后存储在本地每次请求在 header 里带上Authorization: token。后端通过拦截器统一校验没有 token 或 token 过期就直接返回 401前端拦截到 401 后自动跳转登录页。手机号授权这块现在微信的规则是必须通过getPhoneNumber按钮组件触发不能直接调 API 获取。而且企业主体的小程序才能申请该能力个人主体不行。这里有个经验千万别把手机号作为用户是否登录的判断依据很多用户会拒绝授权手机号但他们仍然可以浏览和加购只是下单的时候才强制要求填写收货地址。3.2 点餐与购物车本地缓存还是服务端存储购物车在weixin129里是一个反复改过的模块。最初的版本做得比较“重”——用户每点一次加购前端都调接口去服务端存购物车数据理由是防止用户换手机或者清缓存后购物车丢失。但实际用下来发现这个方案有严重的问题接口压力大点一个菜品就是一次 HTTP 请求高峰期频繁点菜时体验会变差。购物车状态一致性难处理用户在 A 店加购了 5 道菜又跑到 B 店加购购物车里的店铺维度归并逻辑在后端实现起来很绕。最终版本改成了混合策略购物车数据主要存储在小程序本地Storage里结构大概长这样// 本地购物车结构 const CART_KEY cart; // 存储结构以 shopId 为维度分店存 // cartMap: { [shopId]: [{ dishId, name, price, spec, count }] }每次加购、修改数量、删除菜品只更新本地 Storage同时在页面切换时用wx.setStorageSync直接落盘。用户进入确认订单页的时候才把本地购物车数据一次性提交给后端由后端生成订单草稿后续支付成功后清理本地购物车。这个方案的优点是前端交互流畅、接口压力小缺点是用户换设备后购物车确实会丢但对大多数外卖场景来说可以接受。如果你要做“真正多端打通”的购物车建议用服务端存储但要把店铺维度的合并逻辑想清楚。wx.setStorageSync单个 key 的存储上限是 1MBweixin129里购物车数据从来没有超过这个上限所以本地存储完全够用。我还加了一个“存储超限自动清理最旧记录”的兜底逻辑防止异常情况下 Storage 写不进去导致白屏。3.3 微信支付的核心流程与参数细节微信支付是外卖小程序的重中之重也是最容易出问题的环节。weixin129走的是JSAPI 支付核心链路如下小程序端提交订单后端生成订单号并返回给小程序端。小程序端拿到订单号后调自己的后端接口/pay/create后端在微信支付服务端生成预支付单prepay_id。后端将签名后的支付参数返回给小程序端。小程序端调用wx.requestPayment拉起收银台用户输入密码完成支付。微信后台异步通知后端回调接口/pay/notify后端校验签名、更新订单状态、返回 XML 给微信确认接收。有一个很多新手会踩的坑wx.requestPayment里需要传入的paySign并不是直接用商户 API 密钥去签名而是要用商户号、随机串、时间戳、prepay_id 等按固定格式拼接后再用 MD5 或 HMAC-SHA256 签名。官方文档的说法比较抽象我直接贴一个签名前的原始字符串格式appIdwx1234567890abcdef nonceStr5K8264ILTKCH16CQ2502SI8ZNMTM67VS packageprepay_idwx201410272009395522657a690389285100 signTypeMD5 timeStamp1414485394这串字符串按照keyvalue格式用连接结尾加上商户密钥再做 MD5最终得到paySign。顺序不能乱少了任何一项都会签名失败。还有一个容易踩的坑支付回调地址必须是公网 HTTPS 地址并且处理完业务逻辑后一定要向微信返回成功报文{code:SUCCESS}。如果不返回微信会连续多次通知直到超时。我在开发环境里用内网穿透工具把本地服务映射出去接收回调调试效率高很多。但要注意内网穿透工具只适合开发阶段上线前一定要换成正式公网网关。3.4 苹果手机虚拟支付的合规性处理做外卖商城这类实物交易走的还是微信支付-JSAPI不涉及虚拟支付。但如果项目里混入了会员充值、金币购买、付费解锁功能等虚拟商品就需要格外注意苹果的政策虚拟商品在小程序里不能使用微信支付必须走苹果 IAP否则会面临审核被拒甚至下架。weixin129在某些版本里尝试过“会员月卡”这类虚拟权益审核时被提示“含虚拟支付内容需要接入苹果 IAP 或移除该功能”。当时为了合规省事直接把虚拟商品功能从微信小程序端移除改成了 H5 网页端购买。如果你确实需要在微信小程序里做虚拟商品比较稳妥的路径是虚拟商品功能部署在 H5 页面通过web-view嵌入。H5 端对接苹果 IAP 支付或使用第三方支付平台提供的 H5 支付方案。小程序端不给虚拟商品提供入口避免触碰审核红线。因为 IAP 支付涉及到与苹果 30% 抽成之后的结算流程加上退款周期长、用户体验复杂很多团队在微信小程序里干脆不做虚拟支付。这个决定虽然损失了一部分营收但省下来的审核沟通成本和安全风险是值得的。3.5 地图定位、web-view 与文件下载的常见处理外卖项目里地图定位几乎是标配。weixin129使用了腾讯位置服务微信小程序内置支持不需要额外下载地图 SDK。核心步骤在腾讯位置服务控制台创建应用获取 key。小程序端调用wx.getLocation获取经纬度。调用腾讯位置服务 WebService API 做逆地址解析把经纬度转成中文地址展示。wx.getLocation({ type: gcj02, success(res) { const { latitude, longitude } res; // 调腾讯逆地址解析 wx.request({ url: https://apis.map.qq.com/ws/geocoder/v1/?location${latitude},${longitude}keyYOUR_KEY, success(addressRes) { const address addressRes.data.result.address; console.log(address); } }); } });注意wx.getLocation需要在app.json里声明permission字段并且要申请开通“位置信息”接口权限否则调用会失败{ permission: { scope.userLocation: { desc: 您的位置信息将用于展示附近的商家 } } }对于web-view组件外卖小程序的商家公告、隐私政策、富文本活动页都可以用 H5 承载。常见的问题是web-view高度只有屏幕高度没有自适应内容。实际上web-view组件天生就是全屏的里面网页自己内部滚动不存在“改高度”这个操作。需要做的是在 H5 网页内部适配好滚动和尺寸外层小程序页面直接全屏盖住即可。关于视频和图片下载平时做活动页时经常需要在小程序里提供视频预览或海报保存。视频下载在小程序里不能直接完成最合规也最推荐的方式是在视频页提供“复制链接 用户自己到浏览器下载”的引导如果非要做小程序内下载需要用到wx.downloadFile配合wx.saveVideoToPhotosAlbum但前提是视频文件支持 Range 请求并且格式正确。图片长按保存则更简单image组件天然支持长按识别和保存只要没有打开show-menu-by-longpress的禁用开关。3.6 iOS 静音模式下播放音乐的坑外卖小程序支付成功后的提示音、取餐叫号提示音这些场景经常会遇到一个诡异问题安卓手机上声音正常iPhone 只要开了静音就完全没声音。原因是 iOS 上 WebView 和小程序的音频播放默认遵循静音键状态而安卓默认不跟随。微信小程序的解决方式是通过InnerAudioContext设置const innerAudioContext wx.createInnerAudioContext(); innerAudioContext.src https://your-domain.com/audio/notify.mp3; innerAudioContext.obeyMuteSwitch false; // iOS 下忽略静音键 innerAudioContext.play();obeyMuteSwitch默认值是true跟随静音键设置为false之后即使 iPhone 静音键开启也能正常播放音乐。这个属性只在 iOS 上生效安卓端配置了也不会有什么副作用。我当时排查这个问题花了半天时间在真机上反复测试最后发现就是文档角落里的一句话没注意。另外InnerAudioContext播放音频有并发限制如果同时创建多个实例会互相打断。更好的做法是在页面里只创建一个全局音频实例播放前先stop()再play()。4. 真机调试、抓包与常见问题排查实录4.1 真机调试请求无法到达后端开发阶段最头大的问题就是开发者工具里一切正常一上真机所有接口全部失败。weixin129初期也遇到过而且报错信息还各不相同有的直接 timeout有的提示 “url not in domain list”。排查思路按下面几步走基本能定位到问题确认基础库版本微信开发者工具更新后基础库版本和手机上的版本可能不一致低版本基础库对某些 API 支持不完整。在开发者工具右上角可以切换基础库版本尽量用高于线上最低版本的库。确认HTTPS证书完整小程序真机环境强制要求 HTTPS 且证书链完整。在一些免费证书平台申请的证书有时候中间证书缺失浏览器访问没问题但小程序真机会直接报错。确认域名白名单真机环境下非白名单域名请求会被拦截。开发阶段可以暂时勾选“不校验合法域名”但这样只能调试不能预览和发布。正确做法是先把开发环境的域名比如dev-api.yourdomain.com提前配到白名单里。确认局域网IP可达如果你直接连电脑的局域网 IP 调试要注意手机和电脑必须在同一个 WiFi 下且防火墙没有拦截端口。我经常遇到公司电脑防火墙开着导致手机访问不到的情况关闭或放行相关端口后问题就解决了。4.2 iOS 机型网络请求失败率高错误6001异常有段时间weixin129的 iOS 用户反馈支付和下单页面网络请求失败的频率明显高于安卓后台日志里出现了大量的6001错误。查了一圈发现这其实是 iOS WebView 对网络连接的一个限制问题同时发起的并发请求过多时部分请求会被挂起或直接失败。原因在于小程序页面数据加载时如果没做“请求合并”或“请求递归控制”容易出现一次性发出十几个请求的情况。尤其是一个页面组件多、每个组件各自拉接口时最容易触发 iOS 的并发限制。解决办法是并发控制全局封装一个请求管理器给同一时间最多允许发起的请求数设上限比如 5 个超出部分排队等待。页面级数据聚合把商家信息、菜品列表、评价数据合并到一个聚合接口里减少请求数。失败重试机制对 GET 类数据请求增加指数退避重试逻辑第一次失败后隔 2 秒重试再失败隔 4 秒重试最多重试 3 次。这样能有效消化瞬时网络抖动。6001 这个错误码在微信官方文档里没有很详细的解释但结合社区经验大多数时候跟网络连接失败/超时有关按上面的方向处理基本都能缓解。4.3 抓包定位接口问题Fiddler/Charles 实战思路联调阶段经常需要抓包看小程序发出了什么请求、后端返回了什么数据。weixin129里我用的是 Fiddler 抓包。说是“小程序抓包”原理其实不复杂让手机 WiFi 代理指向电脑上的 Fiddler再由 Fiddler 解密 HTTPS 流量。操作步骤大致是这样的电脑和手机连同一个 WiFi。Fiddler 设置允许远程连接Tools → Options → Connections → 勾选 Allow remote computers to connect。Fiddler 开启 HTTPS 解密HTTPS 选项卡 → 勾选 Decrypt HTTPS traffic。手机 WiFi 设置 HTTP 代理为电脑局域网 IP端口填 8888。手机浏览器访问http://电脑IP:8888安装 Fiddler 生成的根证书。再打开微信小程序请求就会在 Fiddler 里被捕获到。这里有个坑安装了根证书之后部分 Android 手机上的微信小程序依然抓不到包这是因为 Android 7.0 以上默认不信任用户安装的 CA 证书。想要彻底解决需要手机 Root 后把证书放到系统目录或者找一台旧版的 Android 测试机。用 iOS 设备配合 Fiddler 能省很多事我一般准备一台专门的测试 iPhone 用来抓包。抓包能帮我们干很多事比如确认请求头是否带上了 token、实际请求的 URL 和开发者工具里是否一致、后端返回的数据结构到底是哪种格式。有时候前后端联调半天对不上打开抓包一看原来是前端请求发错了路径。4.4 返回拦截与自定义导航栏适配外卖小程序的点餐链路比较长首页→商家列表→商家主页→菜品详情→确认订单。用户习惯性地点击左上角返回键有时候希望回到上一级有时候又希望直接跳到首页。weixin129里做了一套“返回拦截”逻辑用来自定义返回行为。微信小程序原生提供的onUnload生命周期函数无法拦截返回操作想拦截必须用自定义导航栏方案然后在返回按钮上做处理// 自定义导航栏返回点击 navigateBack() { const pages getCurrentPages(); if (pages.length 1) { wx.navigateBack({ delta: 1 }); } else { wx.switchTab({ url: /pages/home/home }); } }之所以要判断pages.length是因为如果用户从某个分享卡片直接进入小程序页面栈里可能只有当前这一个页面这时候调用navigateBack会失败需要退回到首页。自定义导航栏还涉及一个基础问题顶部导航栏高度适配。不同手机的胶囊按钮位置不一样计算方法是// 获取菜单按钮胶囊的位置信息 const menuButton wx.getMenuButtonBoundingClientRect(); // 状态栏高度 const statusBarHeight wx.getSystemInfoSync().statusBarHeight; // 导航栏内容高度通常用胶囊按钮的 top 减去状态栏高度再加上胶囊高度与上下间距的估算这套计算逻辑在weixin129里被封装成了一个工具函数所有要用自定义导航栏的页面统一调用保证不同机型上标题文字都能垂直居中、不被胶囊遮挡。4.5 常见问题速查表整理一份weixin129开发过程中遇到的高频问题直接对照着看问题描述常见原因解决方案真机请求全部 timeout域名未加白名单 / HTTPS 证书链不完整配置合法域名、修复证书链iOS 支付后不回调回调地址内网不可达 / 回调返回格式不对配置公网回调处理完返回 SUCCESS播放提示音无声iOSobeyMuteSwitch默认跟随静音键设为false页面被胶囊按钮遮挡未适配状态栏/胶囊高度用wx.getMenuButtonBoundingClientRect计算web-view 空白业务域名未配置小程序后台添加业务域名定位失败/城市错误坐标系不一致 / 未声明 permission统一用 gcj02声明scope.userLocation图片长按无反应未开启show-menu-by-longpressimage组件加上该属性视频下载到相册失败未处理相册权限 / 文件格式问题用wx.saveVideoToPhotosAlbum前先授权5. 上线审核、性能优化与后续扩展思考5.1 外卖类小程序审核的材料与注意事项外卖类目的小程序在微信审核时比较严格weixin129第一次提审就被打回了一次主要是类目资质问题。你要在「小程序后台 - 设置 - 服务类目」里找到“餐饮 外卖/订餐”这一项然后提交《食品经营许可证》。如果你的平台是给别人做外卖配送的还需要提供《增值电信业务经营许可证》ICP 证或相关备案这个门槛让很多小团队在平台化路线上吃了不少苦头。审核注意事项里有几个点必须提前处理隐私政策必须有且内容完整。现在微信对用户隐私保护要求很高小程序内必须提供隐私政策页面说明收集了哪些信息、用途是什么。虚拟支付内容绝对不能有。一旦出现在苹果手机上不能支付的虚拟商品页面大概率会被拦。违规口令和诱导分享词不要出现。外卖活动页经常有“分享到群才能领优惠券”这类设计这类诱导分享在微信生态里是违规的审核不会通过上线后也可能被处罚。5.2 性能优化分包加载、图片压缩与骨架屏外卖小程序页面多、图片多稍微不注意就变成“打开慢、滑动卡”的重灾区。分包加载把商家入驻、订单详情、售后页面这些不常用模块拆进分包里主包保持越小越好。weixin129里把“商家入驻”、“客服聊天”、“发票抬头设置”这些低频页面都放进了分包主包体积从 1.8MB 降到了 1.2MB启动速度明显提升。图片压缩与 CDN菜品图必须做压缩推荐 WebP 格式尺寸按最大展示宽度的两倍生成。开发阶段直接用原图很容易让列表页内存爆炸在 iOS 上尤其明显。骨架屏首页和商家列表这类数据页面在上拉加载时展示骨架屏能大幅降低用户的“白屏焦虑感”。微信原生支持page-meta里的下拉动画自定义配合骨架屏的效果更自然。5.3 后续还能往哪些方向扩展跑通weixin129的基础交易闭环后后续扩展方向其实很清晰一是商家端的独立 App 或小程序把接单、出餐、配送管理从人工后台操作变成移动端作业商家更愿意用骑手也能及时收到取餐通知。二是预约类功能比如类似景区票务预约、校园跑腿这类场景。我做过的预约系统基本就是复用订单模块把“下单”改成“预约档期”把“配送地址”改成“服务地点”再加上日期选择和库存扣减模式是相通的。三是基于用户行为的推荐算法。外卖的复购率很高积累一定订单量后给用户推荐“常点商家的新菜品”“附近评分高的同类店”对转化率的提升非常明显。可以先从规则推荐做起比如“你最近一周点了 3 次川菜附近这几家川菜店评分都高于 4.5”逐步再上模型。四是一个容易忽略但很重要的点售后和客服系统。外卖和纯电商比餐品质量问题时效性要求极高用户反馈必须及时响应否则差评和投诉会直接影响商家评分和平台口碑。微信小程序接入wx.openCustomerServiceChat可以直接拉起微信客服比自建 IM 省事得多。最后再分享一个我做外卖小程序时印象很深的小技巧开发阶段在微信开发者工具的“本地设置”里开启“自动预览”配合一个测试用的童颜相机这个技巧其实没什么用我删掉了——说正经的我能给的最实在的建议是外卖小程序这类交易型项目功能上线只是第一步真正花时间的往往在支付回调、真机兼容、审核资质这些边角料环节。weixin129跑完整个流程我最大的体会就是不管框架多花哨把微信支付、用户鉴权、订单状态流转这三条主链路扎扎实实走通项目就已经成功了八成。如果你也在做类似的项目建议先把这三条链路的数据流图画清楚再开始撸代码能少走很多弯路。