微信小程序在线点餐系统全栈开发：从设计到部署完整实战

前几天还有朋友问我，能不能给他一套“代码能跑、文档能交、有问题还能调”的点餐系统。他原话是：不要那种只放PPT和截图的项目，要能真的编译、真的操作、能写进简历的完整方案。正好，我手头这套基于微信小程序的在线点餐系统属于比较典型的全栈练手项目，从源码到文档再到调试过程都成体系，今天干脆拆开揉碎，把整个项目的设计思路、核心模块、实操细节和踩坑记录都写出来。内容适合课程设计、毕业设计，也适合想快速上手微信小程序全栈开发的开发者参考——你不需要一开始就懂微服务、高并发那些东西，只需要跟着把小程序端、服务端、数据库这条主链路跑通，就能理解一个真实业务系统是怎么从零到一运作的。

这套在线点餐系统解决的核心问题很直接：餐厅线下点餐效率低、人力成本高，用户希望坐下扫码就能看菜、下单、查订单，商家希望在后台统一处理菜品和订单。技术层面可以拆成小程序前端、后端接口、数据库三块，再加上文档撰写和联合调试。下面我按项目从设计到上线的完整流程来写，每一部分都包含我当时做这个项目时的实际思考过程，很多细节是常规文档不会告诉你的。

1. 项目设计与技术选型思路

1.1 需求画像：谁在用这套系统

做任何项目之前，第一步不是写代码，而是搞清楚到底有哪几类用户。在线点餐系统最核心的角色就是两类：食客和商家。食客用微信小程序，扫桌码或者直接搜索小程序进入，看到分类菜单、加购、下单、支付或者选择到店付；商家在后台管理菜品、接收订单、更新订单状态。有些系统还会加一个平台管理员，负责审核商家、处理投诉，但作为学习型项目，角色太多反而拖慢进度，所以我的方案是“小程序用户端 + 商家管理后台”，两条线足够覆盖点餐系统的核心业务闭环。

这里有一个很多新手容易忽略的点：角色边界。为什么要先梳理角色？因为数据权限、接口设计、页面结构全都由角色决定。比如用户端不能访问商家端的订单管理接口，商家端不能直接操作用户的个人信息。如果你拿到需求直接建表，大概率会在权限控制上返工。

以我做的这套系统为例，功能边界大概是这样的：

• 用户端小程序：微信登录、菜品分类浏览、菜品搜索、加入购物车、提交订单、订单状态跟踪、个人中心。
• 商家端H5或小程序后台：登录验证、菜品增删改、分类管理、待处理订单列表、接单/出餐/完成操作、基础数据统计。

这两类用户的数据在底层是打通的：用户下的订单会进入订单表，商家看到的订单列表就是从同一张订单表按商家ID过滤出来的。只是呈现端不一样，权限不一样。

1.2 技术栈怎么选才能少走弯路

当时我选型的时候其实纠结过好几种方案：原生小程序 + 自建后端、uni-app + Spring Boot、微信云开发，甚至纯静态的小程序Demo。最终我选的是“微信小程序原生前端 + Spring Boot后端 + MySQL数据库”这套最经典组合。为什么这么选，我一个个说。

先看前端。微信小程序原生框架用到的语言是WXML、WXSS和JavaScript，如果你已经会一点HTML、CSS和JS，上手成本极低。很多教程推荐uni-app，理由是“一套代码多端复用”。这确实好，但它多了一层编译层，遇到问题时排查链路更长，对初学者来说，一旦样式或API行为不一致，很容易卡住。原生小程序虽然写起来稍微啰嗦，但调试路径短：开发者工具里可以直观看渲染结果和接口返回，适合学习底层逻辑。

再看后端。点餐系统的业务复杂度不高，电商常见的商品、订单、购物车都有，但是维度简化了很多。Spring Boot可以快速搭出标准的三层结构，而且就业市场认可度高。如果你不想用Java，也可以用Node.js的Express或者Python的Flask，但我的经验是，对课程设计/毕业设计来说，Spring Boot的生态文档最全，碰到问题随便一搜就有答案。如果是个人作品想快速上线，也可以考虑云开发，但云开发的业务逻辑不离线、事务支持弱，遇到复杂状态流转反而难调。

我整理了一个选型对比表，供你参考：

方案A还有一层隐藏优势：文档写起来特别顺利。因为后端接口清晰、数据库表结构明确、部署步骤有据可依，写项目文档时每一章都能对应到代码。很多同学最后答辩被问到底层实现，就是因为用了模板代码又不理解——方案A能让你把每个接口、每张表都讲清楚。

2. 核心功能模块拆解与数据库设计

2.1 用户端：点餐体验的核心流程

用户端是离食客最近的一层，体验不好，功能再全也没用。我从页面结构开始拆。

首页是菜品展示页，从上到下通常是：店铺信息区、搜索框、分类导航栏、菜品列表。分类导航栏是左右结构：左侧是分类列表（主食、小吃、饮品、套餐），右侧是对应分类下的菜品。菜品项包含图片、名称、价格、月销量、加购按钮。这里我不会把购物车放在首页正中间，而是用一个底部横条展示已选数量和总价，点击横条可以展开购物车明细，这样既不遮挡菜单，又能随时查看订单进度。

搜索功能建议做后端搜索，不要只在前端过滤当前分类。因为用户可能想搜一个不在当前分类下的菜品。实现方式很简单，后端提供一个搜索接口，接收关键字参数，然后对菜品名称做模糊查询，结果按销量排序返回。

购物车是这个模块的关键。我的设计原则是：购物车数据保存在小程序本地缓存中，因为购物车本身是用户个人的临时数据，没必要每次加购都请求一次后端。但是提交订单时，必须把完整的购物车明细传给后端，后端按事务方式写入订单表和订单明细表。这样做的优点是：操作响应速度快，流量消耗小；缺点是：如果用户换了手机，购物车不同步。对于餐厅点餐场景来说，这完全可以接受，因为用户本来就在当前设备上点餐。

下单流程需要注意桌号或自取信息。如果是堂食，用户要输入桌号；如果是自取，可以选择预计取餐时间。订单提交后跳转到订单详情页，显示订单状态、菜品清单、金额明细、备注。

2.2 商家端：订单处理与菜品管理

商家端我建议做成小程序内的一个独立功能页面，或者单独一个H5管理端，用账号密码登录。用同一套小程序的好处是复用代码，不用额外部署前端，但要注意权限隔离：用户端和商家端不能通过前端隐藏入口来区分，必须在后端接口上做鉴权。

商家端核心功能第一是菜品管理。商家可以新增菜品，填写名称、价格、分类、库存、图片、描述；可以编辑菜品；可以把某个菜下架。这里有个容易踩的坑：菜品分类应该建单独一张分类表，而不是把分类名称直接存在菜品表里。否则商家改一个分类名，所有菜品数据都要批量更新，而且容易产生脏数据。

商家端核心功能第二是订单处理。商家进入订单列表，先看到的是“待处理”状态的订单，每条订单包含桌号、下单时间、用户备注、菜品明细、总金额。商家可以点击“接单”，进入备餐阶段；出餐后点击“出餐”；用户取餐完成后点击“完成”。如果商家觉得某个订单有问题，也可以“退款/拒单”，拒单时建议填写原因。整个订单状态流转清晰，后续做数据统计时也能按状态分组。

商家端还可以加一个最基础的营业统计：今日订单数、今日营业额、热销菜品Top N。统计逻辑不复杂，按日期和商家ID去订单表聚合，用SQL的GROUP BY就能完成，不需要引入重型报表工具。

2.3 数据库设计：表结构决定了业务天花板

数据库设计是整个系统里“返工成本最高”的环节，表没设计好，后面写接口的时候处处别扭。这套点餐系统我最终的核心里有这些表：

• 用户表：用户ID、微信OpenID、昵称、头像、手机号、注册时间。
• 商家表：商家ID、账号、密码密文、店铺名称、店铺公告、营业状态。
• 分类表：分类ID、商家ID、分类名称、排序值。
• 菜品表：菜品ID、商家ID、分类ID、名称、图片、价格、原价、销量、库存、描述、上下架状态。
• 订单表：订单ID、订单编号、用户ID、商家ID、桌号、订单总价、订单状态、备注、创建时间、支付方式。
• 订单明细表：明细ID、订单ID、菜品ID、菜品名称、菜品图片快照、单价、数量、小计。

有一个设计细节我要特别说明：订单明细表为什么要存菜品名称和图片快照？因为菜品名称和价格可能会变，比如商家改价了，如果订单明细里不存快照，那历史订单显示出来的金额和菜品名就会对不上，这是电商领域很经典的“快照模式”。这也是很多初学项目里没注意到的点，你要是能在文档里写出这个设计理由，答辩会很加分。

订单表的状态字段建议用tinyint数字表示，不要直接存中文。比如：

• 0：待接单
• 1：已接单/备餐中
• 2：已出餐/待取餐
• 3：已完成
• 4：已退款/拒单

用数字的好处是后端逻辑清晰，扩展状态方便，需要展示给用户时再映射成中文。但要注意一点：代码里不要散落魔法数字，建议定义一个枚举类或者常量类统一管理，比如ORDER_STATUS_WAIT_ACCEPT = 0。

2.4 核心表结构参考SQL

我当时建的库是点餐系统数据库，核心建表SQL大概长这样（精简版）：

sql复制CREATE TABLE dish (
  id BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT '菜品ID',
  merchant_id BIGINT NOT NULL COMMENT '商家ID',
  category_id BIGINT DEFAULT NULL COMMENT '分类ID',
  name VARCHAR(64) NOT NULL COMMENT '菜品名称',
  main_image VARCHAR(255) DEFAULT NULL COMMENT '菜品图片',
  price DECIMAL(10,2) NOT NULL COMMENT '售价',
  original_price DECIMAL(10,2) DEFAULT NULL COMMENT '原价',
  sales INT DEFAULT 0 COMMENT '销量',
  stock INT DEFAULT 999 COMMENT '库存',
  description VARCHAR(255) DEFAULT NULL COMMENT '描述',
  status TINYINT DEFAULT 1 COMMENT '1上架 0下架',
  create_time DATETIME DEFAULT CURRENT_TIMESTAMP,
  update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='菜品表';

CREATE TABLE orders (
  id BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT '订单ID',
  order_no VARCHAR(32) NOT NULL COMMENT '订单编号',
  user_id BIGINT NOT NULL COMMENT '用户ID',
  merchant_id BIGINT NOT NULL COMMENT '商家ID',
  table_no VARCHAR(16) DEFAULT NULL COMMENT '桌号',
  total_amount DECIMAL(10,2) NOT NULL COMMENT '订单总价',
  status TINYINT NOT NULL DEFAULT 0 COMMENT '订单状态 0待接单 1已接单 2已出餐 3已完成 4拒单',
  remark VARCHAR(255) DEFAULT NULL COMMENT '备注',
  pay_type TINYINT DEFAULT 0 COMMENT '0微信支付 1到店付',
  create_time DATETIME DEFAULT CURRENT_TIMESTAMP,
  update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  INDEX idx_user_id (user_id),
  INDEX idx_merchant_id (merchant_id),
  INDEX idx_status (status)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='订单表';

有一个容易被忽略的问题：订单金额的字段类型不要用float或double，要用DECIMAL。原因很简单：浮点数在计算机里是不精确的。0.1 + 0.2 在二进制里是一个无限循环小数，用DECIMAL可以精确保存两位小数。价格计算出问题在财务上是不可接受的，这也是电商项目的常识。

3. 关键实现细节与实操要点

3.1 微信登录态与Token：最容易翻车的一环

微信小程序登录的标准流程其实不复杂，但很多新手第一次做都会在这里卡住。流程是这样的：

1. 小程序端调用wx.login()，获取一个临时凭证code。
2. 小程序把code发送到自己的后端接口。
3. 后端拿code加上小程序的AppID和AppSecret，调用微信官方接口code2Session，换取openid和session_key。
4. 后端用openid去用户表查用户，如果不存在就自动注册一个新用户。
5. 后端生成一个自定义登录态token，返回给小程序端，小程序端把token存到storage里。
6. 之后每次请求接口，小程序在请求头里带上token，后端通过拦截器校验token。

这里要注意三个坑。

第一个坑：不要在小程序端直接使用AppSecret。AppSecret是后端保密的，如果打包到小程序前端，等于把自家钥匙挂在门口。正确做法是只把code传给后端，让后端去和微信服务器交互。

第二个坑：session_key不能返回给前端。虽然session_key可以用来解密手机号等敏感信息，但它和会话安全相关，泄漏后有被伪造的风险。学习项目里你甚至不需要用到session_key，只需要openid。

第三个坑：token一定要设置有效期。比如7天过期，过期后小程序端要重新调wx.login()刷新token。如果不设有效期，用户token一旦泄露，等于账号永久被劫持。

我贴一个精简的Java后端处理逻辑示例：

java复制@PostMapping("/api/auth/login")
public Result login(@RequestBody LoginRequest request) {
    String code = request.getCode();
    // 请求微信接口 code2Session
    String url = "https://api.weixin.qq.com/sns/jscode2session?appid=" + appid
            + "&secret=" + secret + "&js_code=" + code + "&grant_type=authorization_code";
    String response = restTemplate.getForObject(url, String.class);
    // 解析openid
    JSONObject json = JSONObject.parseObject(response);
    String openid = json.getString("openid");
    if (openid == null) {
        return Result.fail("code失效，请重试");
    }
    // 查库或注册
    User user = userService.findByOpenid(openid);
    if (user == null) {
        user = userService.register(openid);
    }
    // 生成token
    String token = UUID.randomUUID().toString().replace("-", "");
    redisTemplate.opsForValue().set(token, user.getId().toString(), 7, TimeUnit.DAYS);
    return Result.success(token);
}

这段逻辑里我用了Redis存token，如果你的项目没引入Redis，也可以存到MySQL表里，但那样每次请求要多查一次数据库，性能略差。考虑到课程设计/毕设的规模，用Redis是加分项，因为可以顺便把“Redis缓存”写进简历和项目亮点里。

3.2 购物车与订单状态机：前端本地缓存加后端事务

前面说过，购物车保存在小程序本地。具体存储结构可以这样设计：以storage key为cart，里面是一个对象或者数组，数组每一项包含菜品ID、名称、价格、图片、数量。

加购时，先读取本地购物车，判断库里是否已有当前菜品，如果有则数量+1，没有则新增一项。改数量时，数量最小为1，如果减到0则删除该项。这里有一个体验细节：每次加购后，底部横条的总价要实时变化，总价计算不要用数据库接口，直接在前端用reduce方法累加就行，因为菜品价格在下单前是稳定的。

提交订单时，前端把购物车数据传给后端，后端要做的事是：

1. 校验菜品是否仍在上架状态。
2. 校验库存是否充足。
3. 用事务将订单主表和明细表一起写入。
4. 扣减库存，累加销量。
5. 返回订单ID，前端跳转到订单详情。

第2、3、4步必须在一个数据库事务里完成，因为如果在扣库存时失败，订单不能写入成功，否则会出现“订单创建了但库存没扣”的数据不一致问题。Spring Boot里用@Transactional注解就能搞定。

订单状态机我是这样设计的：

• 初始状态是待接单。
• 商家接单后变为已接单。
• 商家出餐后变为已出餐。
• 用户确认或商家确认后变为已完成。
• 任何非终态都可以进入拒单。

这个状态机在代码里要控制流转方向，不能乱跳。比如已出餐不能直接变回待接单，已完成不能再变回已出餐。最简单的实现是在后端状态更新接口里做if判断，更规范的方式是用设计模式里的状态模式，但对于这个体量的项目，写清晰的if判断足够用，而且更容易被答辩老师理解。

3.3 下单时的库存并发问题

库存并发是点餐系统里比较热门的话题。假设店里剩最后一份红烧肉，两个用户同时下单，数据库里的库存是1，两个请求都通过了“库存是否充足”的校验，最后库存变成 -1。这就是超卖。

解决超卖最简单的方式是在更新库存的SQL上加上条件判断：

sql复制UPDATE dish SET stock = stock - 1 WHERE id = ? AND stock > 0;

如果影响行数等于1，说明扣减成功；等于0，说明库存不足，下单失败。这个方案不需要锁机制，在低并发场景下已经够用。你可以在文档里把这个作为项目的技术亮点写出来，比讲一堆理论更实在。

3.4 菜品分页与搜索：接口设计要遵循规范

菜品的数量可能不多，但页面加载时最好还是做分页。为什么？因为如果以后菜品数量增加到几百个，一次性返回全部数据会明显卡顿。推荐的分页方案是后端接口接收page和pageSize参数，返回总条数、当前页数据和总页数。

小程序端用onReachBottom做上拉加载，每次加载下一页时把新数据追加到列表尾部。这里要注意防止重复加载：用一个isLoading标志位，在请求返回之前，如果再次触发上拉加载，直接返回，不让用户疯狂触发。

搜索接口用关键字模糊匹配即可：

sql复制SELECT * FROM dish WHERE name LIKE CONCAT('%', #{keyword}, '%') AND status = 1 ORDER BY sales DESC;

如果商家想支持多字段搜索，比如按分类、按价格区间，可以在这个接口上扩展参数。但不要一开始把所有过滤条件都堆上去，先跑通主链路，再慢慢加。

4. 部署调试全流程与踩坑实录

4.1 后端部署：让项目在你的电脑上先跑起来

拿到源码后，第一步不是打开小程序开发者工具，而是先把后端跑起来。以Spring Boot项目为例，你需要准备的本地环境是：

• JDK 8或11。
• Maven 3.6或更高。
• MySQL 5.7或8.0，并创建一个utf8mb4的数据库。
• Redis，如果代码里用了缓存，需要启动本地Redis。
• IDEA或Eclipse。

先把数据库脚本执行一遍，然后修改application.yml里的配置。这里要特别提醒：MySQL的时区配置经常被忽略。在数据库连接URL上加上serverTimezone=Asia/Shanghai，否则日期时间会出现8小时偏差。我当时第一次跑项目就遇到订单时间比实际时间早了8小时，折腾了半天才发现是时区问题。

yaml复制spring:
  datasource:
    url: jdbc:mysql://localhost:3306/meal_db?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai
    username: root
    password: 你的密码
    driver-class-name: com.mysql.cj.jdbc.Driver

后端启动成功后，可以先用接口测试工具访问一个健康检查接口，确认能通。如果启动失败，优先看端口是否被占用、MySQL是否启动、账号密码是否正确。这三类问题占了启动失败的80%。

4.2 小程序端联调：域名校验和局域网IP

小程序开发阶段，最常见的一个坑就是接口请求报错：url not in domain list。原因是微信小程序要求所有请求的域名必须配置到小程序后台的合法域名里。开发时有两个解决办法：

第一，在微信开发者工具右上角，点击详情 -> 本地设置 -> 勾选“不校验合法域名、web-view（业务域名）、TLS版本以及HTTPS证书”。这样本机可以随意请求IP和localhost。

第二，真机预览时，手机和电脑要在同一局域网下，然后把小程序里请求的baseUrl从localhost改成电脑的局域网IP。比如电脑IP是192.168.1.101，baseUrl就填http://192.168.1.101:8080。注意不要用https，因为本地后端没配证书，HTTP协议就够了。

真机预览时还需要注意：如果后端启动时设置了防火墙，可能拦截来自手机的请求，需要在电脑防火墙里放行8080端口，或者临时将“专用网络”的防火墙关掉。

4.3 云开发方式：为什么我建议先别用它

微信云开发可以免鉴权直接在小程序端调用云函数和云数据库，开发速度极快。如果你的目标是三五天做一个能演示的Demo，云开发确实很香。但如果你要做课程设计或毕业设计，云开发有个明显短板：答辩时老师问你数据库表怎么设计、接口怎么做权限控制、服务器怎么部署，你很难通过云开发来展示完整的后端能力。

反过来，如果你已经用Spring Boot做了一遍完整后端，之后想尝试云开发，反而更容易理解它的设计逻辑。所以我的建议是：传统自建后端作为主方案，云开发作为附加了解项，两者都写在文档里，显得你有技术广度。

4.4 上线之前：这些配置不改必出事

如果要把项目部署到服务器上，有几件事在开发阶段可以不做，但上线前必须做。

第一，域名备案和HTTPS证书。微信小程序正式环境强制要求所有请求域名必须是HTTPS，同时域名必须在微信公众平台配置为request合法域名。买一台云服务器、买个域名、申请免费SSL证书并配置到Nginx，这是常规操作。

第二，关闭调试模式。开发时为了方便看接口日志，后端可能开了debug级别日志，上线前要调成info级别，避免日志文件快速膨胀。

第三，接口防刷。点餐系统虽然业务简单，但接口裸奔很容易被脚本刷。最简单的防护是给关键接口加上频控，比如同一用户一分钟内最多提交10次订单。用拦截器加一两个计数器就能实现。

第四，数据备份。MySQL数据库每天定时备份，写个shell脚本用mysqldump导出，保留最近7天的备份即可。这个操作不复杂，但是很多项目上线后真正出事时才后悔没做。

5. 常见问题排查与技巧实录

5.1 典型问题速查表

我在开发和调试过程中踩过不少坑，有些坑会反复出现，整理成表格方便你自查：

5.2 联调过程中最耗时的其实是“数据一致性”

很多新手以为写代码最耗时间，实际上联调阶段才是最容易拖延进度的。尤其是购物车、下单、订单状态刷新这三块，前端和后端各有各的状态，一旦中间某一步接口返回异常，整个流程就断了。

我的排查思路是：先固话后端接口。用接口测试工具把每个接口对应的请求参数、返回结构固定下来，自己先构造数据测一遍。后端没问题，再和小程序前端对接。如果你直接写一个页面就去调接口，报错时根本分不清是前端参数传错还是后端逻辑错，浪费的时间成倍增加。

还有一个技巧：在小程序里封装统一的request方法，所有接口都走同一个函数，在函数里统一附带token，统一处理HTTP状态码。这样排查问题时只需要看一处日志，而不是在每个页面里找散落的请求代码。

5.3 性能和体验优化：骨架屏、图片压缩、分包

点餐系统页面虽然不多，但体验优化空间很大，尤其是菜品图片多的时候。

图片是最常见的优化点。小程序端图片建议压缩后再上传，不要直接传原图。一张500KB的图片和一张50KB的图片，在列表页的加载速度差异是肉眼可见的。图片格式优先用WebP或JPG，尺寸控制在800px宽度以内。商家端上传图片时，可以用Canvas压缩再上传，这一步能明显降低流量消耗。

列表页可以考虑做骨架屏。小程序开发者工具里可以编写自定义loading组件，用灰色色块模拟菜品卡片布局，接口数据返回前显示骨架屏，返回后显示真实内容。这个细节虽然小，但在答辩演示时能给人一种“这个项目考虑到了真实用户体验”的好感。

如果以后要扩展更多功能，比如增加营销模块、会员模块，页面数量会大幅增加。到时候就要用到微信小程序分包机制：把商家端、订单详情、个人中心等非核心页面放到分包里，主包只保留首页和公共组件，缩短小程序冷启动时间。

5.4 后续还能怎么扩展

这套点餐系统做完基础版本后，扩展方向其实很多，而且每个方向都不难，关键看你想往哪个方向深入：

• 接入真实微信支付：申请微信支付商户号，用下单接口替换“模拟支付”，处理好支付回调更新订单状态。
• 增加桌码扫码点餐：给每张桌子生成一个小程序码，用户扫码自动带上桌号，减少手动输入。
• 对接云打印机：商户接单后，通过接口调用云打印服务自动打印订单小票。
• 增加会员积分和优惠券：在订单金额计算环节加入满减、折扣逻辑，订单表增加优惠金额字段。
• 多商户平台化：将商家维度升级为平台+商户，商户申请入驻、平台审核，这就慢慢接近美团点餐的业务模型了。

每一步扩展都对应新的技术点，比如支付回调、消息推送、扫码参数解析、权限体系升级等。这些如果都能写进文档中作为“项目展望”，你的项目完整度会高很多。

最后分享一个个人经验：这种全栈项目，最值得投资的不是代码量，而是调试能力。遇到问题别急着改代码，先复现、再定位、再修复，最后补一个测试用例或者日志记录。我在做这个点餐系统时，最耗时的环节其实是手机真机调试时的局域网联调——后端、小程序、网络环境、系统时间四处都有变量，当时踩了三次坑才总结出上面的检查顺序。如果你也打算做类似项目，建议提前在电脑上把接口全部测稳，再碰真机预览，这样能省下一大半时间。