仿美团外卖小程序前后端代码解析：从登录到订单状态机实战

简介前后端分离架构是现代小程序开发的基石它将界面展示与业务逻辑解耦让同一套后端接口可服务于多个端。在订单类业务中订单状态机是核心设计模式通过定义待付款、待接单、配送中等状态及合法流转确保数据一致性。Spring Boot 作为主流后端框架配合 Redis 缓存和微信登录鉴权能高效支撑外卖场景下的高并发请求。这类代码在毕业设计、求职面试和 Demo 搭建中都有广泛需求。以仿美团外卖小程序项目为例深入解析其前后端实现覆盖登录、下单、支付、部署等关键技术点帮助你快速掌握可落地的工程实践。1. 拿到这套“仿美团外卖小程序”代码后先想清楚它到底帮你解决什么问题说实话我前后接触过好几份外卖小程序的项目代码有学生交的、有培训班出的、也有商业项目里扒出来的质量参差不齐。但“仿美团外卖小程序-后端前端代码”这种带后端、带前端打包在一起的项目反而是最适合拿来学习和二次开发的样本。为什么这么说因为它天然包含了一条完整的业务闭环用户打开小程序 浏览商家 加购商品 提交订单 支付 商家接单 配送完成 评价同时后台还有商家管理、订单管理、分类管理这些运营侧的功能。这种项目不像单纯的前端页面那样只有壳子也不像纯后端接口那样看不到业务效果它是一个能跑起来的完整系统。这一套代码直接能让你搞清楚三件事前端小程序如何调后端接口从 wx.request 的封装、token 注入、再到列表分页、订单状态的渲染每一步都有现成代码可以参考。后端接口如何设计RESTful 风格的路由、统一返回格式、登录鉴权、订单状态机、支付回调这套代码里全部有。前后端如何联调部署小程序端开发环境怎么配代理、后端跨域怎么处理、真机上怎么连本地服务实际上手走一遍就会记得很牢。适合谁来参考也很明确准备做毕业设计的同学、想转行进入小程序开发方向的新人、以及需要给公司搭建一套外卖点餐Demo用于提案或演示的产品/项目经理。如果你是想直接上线商用那这套代码只能作为起点因为商业外卖还涉及商家结算、骑手调度、区域规划、实名认证这些复杂逻辑这里通常是不完整的。有一点我想先说清楚很多人下载完这种 rar 压缩包第一件事就是解压、启动、看效果这个习惯其实不太好。代码能跑只是最低要求你要先花半小时把目录结构、技术栈、数据表之间的关系理一遍后面改起来才有底。后面每一节我会按照“先看懂设计、再动手实操、最后排查问题”的顺序把这套代码从里到外讲透。2. 项目整体设计与技术选型为什么这个项目结构值得你花时间研究2.1 前后端分离到底分的是什么这套代码最标准的形态一定是前后端分离工程。“前”不是指小程序端单方面而是包含两个独立前端一个是面向 C 端用户的微信小程序另一个往往是面向商家或平台运营的 Web 管理后台Vue/React 写的“后”则是统一的 API 服务端。小程序端只负责 UI 渲染和用户交互所有业务规则、数据校验、状态变更都在后端完成。这种分离设计的好处在于逻辑更清晰。改小程序页面不会动到业务逻辑改后端接口不会影响页面展示。同一套后端接口可以同时服务小程序、App、Web 端只要约定好接口协议就行。开发可以并行。前端和后端同学各自调试最后通过接口文档统一联调。当然代价也很明显你需要处理跨域、需要管理 token、需要维护接口文档、联调时两端容易互相甩锅笑。但这些都是工程化开发的必修课早点习惯不是坏事。2.2 后端技术栈怎么选Spring Boot 还是 Node.js这类外卖项目后端常见两种技术路线这套代码如果用的是 Java 技术栈大概率是 Spring Boot MyBatis-Plus MySQL Redis如果用的是 Node.js则是 Express/Koa Sequelize/Prisma MySQL。两种方案都能跑但对不同诉求的人来说选择理由完全不同对比维度Spring Boot 方案Node.js 方案上手门槛较高需要理解 Java、Maven、IoC较低JavaScript 一套语言通吃企业招聘需求岗位多适合以此作为求职项目岗位相对少一些但前端转后端更顺畅生态成熟度非常成熟支付、权限、工作流都有现成方案成熟但复杂业务下需要自己拼装更多组件适合场景毕设、面试、传统企业数字化转型项目学习前后端同构、追求快速开发如果是以找工作为目标我建议优先看懂 Spring Boot 这套。原因很现实很多公司的后端面试会围绕这些技术栈展开你用外卖项目里的订单状态机、缓存设计、支付回调这些点去回答问题会比背八股文打动面试官得多。2.3 数据库表设计外卖业务的骨架全在这几张表里不管代码里有多少文件最值得先看的一定是数据库脚本。这套代码的 sql 文件里核心表一般有这几张用户表 (user)存储用户微信 openid、昵称、头像、手机号、余额、状态等。商家表 (merchant/shop)店名、地址、经纬度、起送价、配送费、公告、评分、营业状态。商品表 (product/goods)所属商家ID、分类ID、商品名、图片、价格、库存、销量、上下架状态。商品分类表 (category)每个商家下的分组比如热销、主食、饮品。购物车表 (cart)用户ID、商品ID、数量、选中状态。注意有些项目用本地缓存代替后端购物车表。订单表 (orders)订单号、用户ID、商家ID、总金额、配送地址、订单状态、支付时间、创建时间。订单明细表 (order_item)订单ID、商品ID、商品名、单价、数量、小计用于快照。地址表 (address)用户收货人、电话、详细地址、经纬度、默认地址标识。评价表 (comment)用户对订单、商家的评分与留言。关键点在于订单状态字段。常见的做法是用 int 存一个状态码比如 0 待付款、1 待接单、2 配送中、3 已完成、4 已取消再配合 create_time、pay_time、finish_time 这些时间字段来追溯整个生命周期。这里有个新手常犯的错误直接用字符串存状态名比如 “pending”“paid”虽然可读性好但查询效率低、状态枚举不好控制还是用数字码加注释更合理。经纬度字段在商家表里通常用 decimal(10, 6) 或 double 存储为什么要留 6 位小数因为经度纬度精确到小数点后 6 位时精度大约 0.1 米对于外卖场景下计算门店距离完全够用。如果你的代码里用的是 float我建议立刻改成 decimal否则后面做距离排序会越来越不准。2.4 缓存与文件存储Redis 和对象存储用在哪外卖场景里 Redis 一般用在三处一是用户登录态 token 缓存二是首页或商家信息缓存三是库存扣减的原子操作。如果你看到代码里引入了 Redisson 或 Jedis但又没在关键业务里应用那这部分多半是预留扩展。商品图片、商家头像这类静态资源通常直接传本地 Nginx 目录或者对象存储阿里云 OSS / 腾讯云 COS。开发环境里偷懒的方法是把图片放在后端 static 目录下用http://localhost:8080/static/xxx.jpg直接访问但上线后这种做法不可取一是没 CDN 加速二是后端重启后上传文件容易丢。3. 前端小程序核心模块拆解从登录到下单的完整链路3.1 微信登录与 token 管理小程序端“我是谁”的问题小程序端没有传统意义的密码登录微信早就替你解决了身份问题。整体流程是前端调用wx.login()拿到临时凭证 code。把 code 发给后端后端拿 code 调用微信的code2Session接口换取用户的 openid 和 session_key。后端从数据库查这个 openid 是否存在不存在则自动注册然后生成一个自定义 tokenUUID 或 JWT。前端收到 token 后存在本地缓存里wx.setStorageSync(token, value)之后每次请求都带上这个 token后端经拦截器校验身份。这里面有几个容易踩的坑code 只能用一次而且有效期只有五分钟。如果后端拿着 code 调用微信接口失败前端需要重新wx.login()获取新 code。token 不要过期时间设置太长。我见过有人把 token 设置成 30 天有效用户卸载重装小程序后 token 依然有效这其实有点风险。一般建议 7 天左右配合 wx.checkSession 判断登录态。不要在本地缓存敏感数据。用户手机号、收货地址、余额这些数据一律走后端接口获取前端只保留 token 和基础用户信息。3.2 首页与商家列表定位、距离计算、排序首页基本就两大块头部搜索框和下面的商家列表。商家列表背后涉及两个核心问题第一定位。小程序里通过wx.getLocation获取用户经纬度时需要声明requiredPrivateInfos: [getLocation]并在小程序管理后台申请开通权限。注意微信在隐私政策上卡得很严如果你没在 app.json 里配置好或者没在后台申请类目权限真机上 call 这个接口会直接失败。开发工具里模拟定位没问题到了真机就开始报错这是最常见的坑。第二距离计算与排序。拿到用户经纬度和商家表中的经纬度后使用 Haversine 公式计算球面距离distance 2 * R * arcsin(sqrt(sin^2((lat2 - lat1)/2) cos(lat1) * cos(lat2) * sin^2((lng2 - lng1)/2)))R 约等于 6371 公里。如果觉得这套公式太复杂也可以直接用后端 MySQL 的ST_Distance_Sphere函数5.7 以上版本支持一条 SQL 就能按距离排好序。需要注意的是距离计算不要放在分页之后做否则用户只在前几页里看到商品后面的商家排序就乱了正确做法是先算出所有商家与用户的距离再排序分页。3.3 商品浏览、SKU 选择和购物车设计商家详情页一般包含三个组件分类导航栏左侧竖排分类、商品列表右侧滚动、底部购物车栏显示总价和结算按钮。这里对性能要求最高因为商家如果有一百多个商品一次性渲染全部图片会很卡很多成熟的代码会使用 vant-weapp 的Sticky吸顶组件搭配分块加载来优化体验。购物车是这个项目里最微妙的设计点。购物车到底放前端还是后端我去翻了大量代码发现各有取舍纯前端购物车把选中的商品、数量存在wx.setStorageSync(cart)里。优点是实现简单、交互流畅、不占服务端资源缺点是换个设备购物车就没了而且如果商品价格或库存发生变化下单时才发现不一致容易引起纠纷。后端购物车每次加购都调接口服务端存 MySQL 或 Redis。优点是多设备同步、价格库存以服务端为准缺点是每个加购动作都要请求一次接口用户高频操作时后端压力会增加并且请求失败时会丢操作。模拟美团这种商业产品时购物车实际上做了缓存 服务端校验的折中前端本地存一份实时数据用于 UI 展示提交订单时把整个购物车商品清单发给后端后端重新校验价格和库存。但绝大多数教学代码为了省事都是纯前端购物车这一点你拿到代码后可以先确认。还有一个细节是购物车的“单选按钮”问题。很多人看代码时会疑惑为什么购物车里某个条目要加radio-group或带checked的 checkbox。其实这是“部分结算”功能用户不是每次都要把购物车里所有商品一次下单可能只想买其中两样。所以购物车列表里的每个条目需要有一个选中状态提交订单时只算选中的商品。3.4 下单流程与订单列表页面跳转、防重、倒计时从购物车点击“去结算”后流程是这样的跳转到订单确认页展示商品清单、计价明细、收货地址。用户确认地址后点“提交订单”。前端先检查登录态和地址是否完整再调用后端POST /order/create接口。后端创建订单状态为“待付款”返回订单 ID。前端拿到订单 ID 后跳转到收银台页面调用统一下单接口发起支付。支付成功后回到订单详情页状态变成“待接单”。这里最常被忽视的问题是“防重复提交”。用户手速快多点几次“提交订单”后端会创建多笔一模一样的订单。解决思路很简单但很实用前端按钮加 loading 状态点击后不可再次触发。后端用用户 ID 商家 ID 商品 hash 做幂等性校验短时间重复请求直接返回同一个订单号。更稳妥的做法是前端生成一个请求唯一标识 requestId后端对 requestId 做去重。订单列表页还有一个体验细节对“待付款”状态的订单显示倒计时“还剩 xx 分 xx 秒自动取消”。实现方案也不难订单创建时后端记录 expires_time前端用一个定时器每秒计算剩余毫秒时间到 0 就自动更新状态、改变按钮文案。注意定时器要设定在页面 onShow 时启动、onHide 时清除否则用户切到其他小程序页面时定时器还在跑白白耗电。4. 后端接口与业务逻辑解析订单状态机和支付是最值钱的两块4.1 统一返回格式与全局异常处理看后端代码先看它的 controller 包和 common 包的规范。这套代码里后端对外返回的数据一般是这样{ code: 200, message: success, data: { } }code 为 200 表示成功非 200 表示业务异常比如 401 未登录、403 无权限、500 服务异常。封装统一返回格式的好处是前端可以非常简单地判断请求是否成功status 等于 200 再取 data否则统一 toast 提示 message。全局异常处理在 Spring Boot 里通常用RestControllerAdvice加ExceptionHandler把各类异常统一转换成上面的返回格式这样前端不用在每个接口里都写 try-catch 处理业务异常。这套代码里如果连这个都没有那后端规范是不过关的你自己可以补上。4.2 订单状态机外卖业务最核心也不可跳过的逻辑订单状态是最值得研究的部分。简单的一个“状态”字段背后隐含了一整套业务流程的一致性需求。以一个标准外卖订单为例待付款(0)下单成功等待用户支付。待接单(1)支付成功商家在后台能看到订单可以选择接单或拒单。配送中(2)商家接单后商品出餐并交给配送员在简化版里可能是商家自配送或到店自取。已完成(3)用户确认收货或者系统超时自动完成。已取消(4)用户主动取消、商家拒单、超时未支付自动取消。后端代码里每一次状态变更都应该被记录。你经常会在代码里看到一个order_status_log或order_action表记录状态从几变到几、操作人是谁、什么时间变的。这是运营排查问题的重要依据以后你接手任何订单类项目第一件事就是找这个日志表。这里面还有两个常见业务规则待付款订单超过 15 分钟自动取消实现方式有两种一种是消费者端看到订单后调接口取消另一种是后端定时任务扫表把超时订单置为取消。前者实时性好但用户不打开页面就永远不会触发后者需要定时任务调度但会占用数据库查询资源。生产环境更常用延迟队列或 Redis 过期 key 监听来实现。已完成订单才能评价评价接口要先查订单状态不是已完成状态直接抛业务异常。这个校验在写代码时很容易漏但不校验的话用户可以给任何一个订单刷评价数据就乱了。4.3 支付对接与模拟支付开发环境怎么绕开真实支付真实微信支付流程涉及商户号、API 密钥、证书等一堆东西大部分开发者手头都没有。所以这套外卖代码在开发环境里通常会用“模拟支付”用户点“去支付”前端弹窗提示“模拟支付成功”后端直接调用回调逻辑把订单状态改成待接单。但如果你要接真实支付流程大概是后端生成订单后调微信支付统一下单接口传入订单号、金额、回调地址。微信返回 prepay_id。后端把签名信息返回给小程序端。小程序端用wx.requestPayment拉起收银台让用户完成支付。微信服务器异步回调后端支付结果接口后端验证签名和金额后更新订单状态。这里最坑的就是第 5 步回调。调试时你会发现回调地址必须是公网 HTTPS 地址本地 localhost 收不到。解决方案有两个方向一是用内网穿透工具比如 cpolar、natapp 这类把本地端口映射到公网临时域名二是在代码里加一个手动触发入口模拟微信回调用 curl 调一下接口直接看效果。开发阶段我推荐第二种稳定且不用依赖外网。支付回调还有一个必须考虑的点幂等性。微信支付回调可能会重试多次前端的请求也可能重发所以后端在回调处理里第一件事是查订单当前状态如果已经是“待接单”就直接返回成功不重复处理否则就会发生同一笔订单被重复扣库存、重复加积分的后果。4.4 后端跨域与接口文档配置小程序端不像浏览器那样有强制的同源策略限制所以一般不存在浏览器里的 CORS 报错问题。但如果你在 Web 管理后台里也调了同一个后端那就必须处理跨域。Spring Boot 里通常有三种做法实现WebMvcConfigurer重写addCorsMappings配置允许的域名、方法、请求头。使用CrossOrigin注解加在 Controller 或方法上。通过网关层统一加响应头。最省事的是第一种可以一次性配好全局策略。注意allowedOriginPatterns不要配成*生产环境要精确指定域名否则安全策略审计过不去。很多代码里配置的是本地运行没问题、上生产就各种 403大概率就是这里的原因。接口文档方面Spring Boot 项目一般集成 Swagger 或 Knife4j启动后访问/doc.html就能看到每个接口的参数定义和响应示例。拿到这套代码后我建议先花半小时把每个接口的 path 看一遍弄清楚order/*、user/*、merchant/*各自的职责就等于拿到了一张项目地图。5. 前后端联调与部署从本机跑通到上线这中间有多少隐形的坑5.1 本机启动顺序不对项目永远跑不起来不管代码是谁写的一套前后端分离项目要本地跑起来必须按依赖关系启动先启动 MySQL、Redis 这些中间件确认端口可连接。初始化数据库导入init.sql或schema.sql文件。修改后端配置文件里的数据库账号密码、Redis 地址。启动后端服务确认/doc.html或某个健康检查接口能通。启动管理后台前端如npm run dev。用微信开发者工具导入小程序前端代码配置开发环境地址编译预览。经常有人直接跳过第 1 步就去跑后端然后报一个Cannot connect to MySQL的错就以为代码有问题。其实九成都是自己环境没准备好。如果后端启动日志里出现port already in use大概率是 8080 端口被占用在 IDEA 里可以直接改application.yml的 server.port或者用命令把占用进程找出来清掉。5.2 小程序真机调试连不上本地后端这是联调阶段出现频率最高的问题。开发工具里预览没问题但手机一扫码就白屏或网络报错。原因很简单手机上的小程序是运行在你的真机里它没法通过 localhost 访问到你电脑上的后端服务。解决办法确保手机和电脑在同一个局域网内。后端地址写电脑的局域网 IP比如http://192.168.1.100:8080不是 localhost。在微信开发者工具的“详情 - 本地设置”里勾选“不校验合法域名、web-view业务域名、TLS 版本以及 HTTPS 证书”。如果后端服务只监听 127.0.0.1需要改配置为0.0.0.0才能被局域网访问。如果后端接口是 HTTPS 且证书无效真机上仍然会被卡住。开发时可以临时用小程序的“不校验合法域名”选项跳过但上线前必须换成有效证书、配置合法域名否则永远只能在自己开发者工具里玩。5.3 用抓包工具定位前后端联调问题小程序前端报错时最常见的问题就是“不知道是前端传参问题还是后端逻辑问题”。这时候需要抓包工具看请求和响应。我常用的办法是在微信开发者工具里打开调试器切到 Console 和 Network 面板。先看请求是否发出、状态码是多少、响应体是什么。如果响应体里后端返回了{code: 500}就打开后端日志看对应的异常堆栈。如果请求根本没发出去优先检查前端拦载器里 token 是否取出失败、request 封装是否把 URL 拼错。对于后端接口本身遇到找不出原因的问题时我直接用 Postman 或 Apifox 手动调一次接口用同样的参数发一遍很快就能分清是前端传参不对还是后端逻辑有 bug。抓包时注意查看 HTTP 状态码和响应体结构不要只看一眼“请求失败”就没了。5.4 上线部署环境的选择服务器、域名、HTTPS小程序上线对网络环境有硬性要求所有请求域名必须是 HTTPS且在小程序后台配置了白名单request 合法域名备案要求也要过。这就决定了部署方案的底线域名一定要有并且要 ICP 备案。域名要配置 SSL 证书才能提供 HTTPS。后端服务要部署在有公网 IP 的服务器上通过 Nginx 反向代理到 Java 服务端口同时由 Nginx 完成 HTTPS 终止。部署时前端的小程序代码也要把接口地址从本机 IP 改成线上域名。还有一种做法小程序前端代码里不写死地址通过一个config.js文件统一管理环境变量构建时选择环境。这样开发和上线切换起来会很方便。后端部署时 JAR 包启动方式很简单nohup java -jar order-backend.jar --spring.profiles.activeprod app.log 21 建议不要用--server.port覆盖配置文件里的端口而是把端口写死在 profile 对应配置文件里这样既可以用环境参数区分环境也不容易搞混。6. 常见问题与排查技巧实录6.1 后端启动失败MySQL、Redis、端口占用现象原因解决办法启动日志报Communications link failure数据库没启或连接串错误检查 MySQL 服务核对 yml 里的 URL、用户名、密码启动日志报Unable to connect to RedisRedis 没启或密码不对启动 redis-server检查密码配置启动日志报Port 8080 was already in use端口被占用杀掉占用进程或改 server.port启动成功但接口 404没有正确扫描到 Controller 包检查启动类上的ComponentScan或MapperScan配置数据库表缺失没有导入初始化 SQL执行 doc 或 sql 目录下脚本这个表里的问题几乎每个项目都会遇到一次属于标配级的排障清单。6.2 小程序端登录失效、token 丢失用户用着用着突然请求全部变成 401解决思路先看后端日志确认是被拦截器拦的还是 token 过期。如果 token 过期前端每次请求返回 401 时统一跳转登录页重新走wx.login()流程。如果 token 丢失大概率是本地缓存被清掉了可以设置一个全局“重新登录”的事件总线统一触发。有的项目会把 token 存在 Storage 里但没做过期时间校验导致用户换设备后旧 token 仍然能访问接口。建议后端在拦截器里每次校验 token 的有效期超过 7 天强制重新登录。6.3 支付回调收不到、状态不同步开发环境用模拟支付的时候如果点击“支付成功”后订单状态还是“待付款”优先排查顺序前端调用模拟支付成功的接口了吗是不是回调函数里还没有把订单状态刷新后端回调接口地址是不是写死了公网地址导致本地环境回调失败回调接口入参是不是从 request body 里取的但模拟支付实际传的是 query string如果接真实支付收不到回调最可能的原因是回调地址无法被微信公网服务器访问。确认这一点前先用 curl 手动调用一次回调地址看返回什么码再继续查下去。6.4 库存超卖并发环境下如何保证数据一致外卖场景里的库存问题虽然没有秒杀那么极端但也不能忽视。多个用户同时点同一道菜如果代码是“先查库存、够就减”在高并发下会出现超卖。最简单有效的办法是把库存扣减做成一整条原子 SQLUPDATE product SET stock stock - 1 WHERE id #{productId} AND stock 0;返回影响行数大于 0 才算扣减成功。商品表和订单明细的写入要放在同一个数据库事务里防止扣了库存但订单没生成。如果项目里用了 Redis也可以先用 Redis 的DECR原子操作扣减再异步把结果同步到数据库但注意 Redis 和 MySQL 的数据一致性要额外处理不建议新手一开始就上这套。6.5 前端页面渲染不出数据小程序调用后端接口拿到了数据但页面上什么都不显示这种情况一般三个原因数据绑定字段不一致。后端返回的是shopName前端绑定的是storeName控制台不会报错但页面就是空白。异步时序问题。列表数据在 onLoad 里异步获取但 WXML 里已经同步渲染了初始值是空数组导致页面短暂空白。用loading状态控制页面切换会好很多。setData 的数据结构太深或者数据量太大超出小程序对单次 setData 的 1MB 限制页面会直接卡住或报错。解决办法是分页加载、减少单次 setData 的数据量。这种问题排查时可以打一条 console.log 输出接口返回的原始 JSON和后端返回的数据结构逐字段核对一遍一般十几分钟就能定位。7. 我从这套项目里总结的几点个人经验写到这里我再分享几个我实际踩过的坑和体会希望对你有帮助。第一拿到这种前后端都有的小程序项目不要急着加功能先把整个流程完整跑通一次。我见过太多人拿到代码改了两行配置就开始写新页面最后发现支付回调不好使、订单状态对不上又回头来重新查基础逻辑。先跑通“下单 支付 接单 完成”这条主干链路项目才算真正掌握。第二无论你最终用不用 Spring Boot都建议把后端订单状态机的代码原原本本读一遍。外卖项目的订单状态流转非常有代表性以后你做电商、做预约系统、做售后工单都能复用这套思路。状态的定义、状态之间的合法跳转、超时自动取消的逻辑这些才是代码里最值钱的部分。第三关于“仿美团”这件事我劝大家不要真的把代码拿去上线商用。美团、饿了么这种平台有大量精细化运营的能力不是一个小程序能cover的比如智能调度、实时定价、商家评分体系。你把它当学习和面试作品完全没问题但要说商业化还是需要把你的业务差异化和运营策略想清楚再来谈代码层的事。第四这套代码给你的最大价值其实是“面试里能讲的故事”。简历上写“我做过一个外卖小程序”面试官关注的无非这么几点项目架构是什么、你负责哪部分、订单状态怎么设计、支付流程怎么做、高并发下怎么防超卖。你把上面几个问题想明白讲出来的深度跟背答案完全是两个水平。最后再补一句代码可以下载经验必须自己踩。如果你想一个月后能流畅地讲清楚这个外卖项目的每一个模块最好的练习方式是拿到代码后把主流程自己手写一遍先把后端订单接口写出来再写前端下单页最后打通支付。写的过程遇到的所有问题都会变成你真正会的东西。本文还有配套的精品资源点击获取