微信外卖小程序答辩PPT：Java后端架构与核心代码解析

简介：这份PPT资源面向计算机专业学生与Java Web开发者，用于微信外卖小程序项目的毕业答辩或课程汇报。内容围绕管理员服务端、商家服务端与用户客户端三大模块展开，涵盖食品类型管理、商户信息管理、外卖信息管理、订单管理及用户个人中心等功能设计，并梳理了Java面向对象、跨平台与垃圾回收机制，以及MySQL数据库、微信开发者工具调试、代码体积限制等关键技术要点。资源包共1个pptx文件，约27.67MB，以幻灯片形式呈现课题背景、需求分析、系统设计、数据库设计与整体测试等章节，结构完整，可直接用于答辩演示或作为项目文档参考。目前已有74人学习，适合需要快速搭建外卖类小程序方案、理清功能模块划分与答辩思路的读者借鉴使用。

1. 从一份答辩 PPT 反推：微信外卖小程序 + Java 后端到底要讲清哪几件事

很多人拿到「基于 Java 的微信小程序微信外卖小程序答辩 PPT」这个题目，第一反应是去找模板、套配色、堆截图，结果答辩现场被老师三连问就卡壳：你的订单状态怎么流转？库存超卖怎么防？小程序登录拿到的 code 换 openid 那一步后端做了什么？这份 PPT 真正要承载的不是排版，而是一套能自圆其说的技术链路——微信小程序做用户端入口，Java（常见是 Spring Boot + MyBatis-Plus）做业务后端，MySQL 存订单、菜品、用户，Redis 顶住秒杀和购物车，最后用一页架构图把「请求从微信客户端出发，经过登录鉴权、下单、支付回调、状态机流转」讲明白。它适合正在做课程设计、毕业设计、实训答辩的开发者，也适合想把自己项目讲成技术故事的人。下面按「先立住技术骨架，再落到能复现的代码和参数，最后讲答辩现场怎么扛住追问」的顺序拆开讲。

2. 答辩 PPT 的技术骨架：小程序端、Java 后端、数据层怎么分工

一份能扛住追问的答辩 PPT，第一页架构图就要把三层职责划清楚，否则后面每一页都在打补丁。微信外卖小程序这类项目，本质是「轻前端 + 重后端」：小程序只负责渲染菜单、收集用户操作、调接口；真正的价格计算、库存扣减、订单状态流转全部放在 Java 后端，因为客户端可以被篡改，价格和库存绝不能信前端传上来的值。这一章先把三层的边界和选型理由讲透，再给出可以直接画进 PPT 的模块划分。

2.1 小程序端只做三件事：渲染、收集、调接口

微信小程序端在答辩里最容易被问「你前端做了什么」，如果回答「画页面」就太单薄了。合理的说法是：小程序端负责三件事——把后端返回的菜品列表渲染成可点单的界面、收集用户的选择（规格、数量、备注）并组装成请求体、通过wx.request调用后端接口。价格展示可以用后端返回的单价做前端预览，但提交订单时只传菜品 ID 和数量，金额由后端重新算。

登录这块是答辩高频考点。小程序调用wx.login()拿到临时code，这个 code 只能用一次、五分钟过期，必须由后端拿着 code + AppID + AppSecret 去微信服务端换openid和session_key。AppSecret 绝对不能放在小程序端，这是安全红线，也是老师最爱问的点。换回来的 openid 用来标识用户身份，后端据此签发自己的 token（常见是 JWT），后续请求带 token 鉴权。

// 小程序端登录：只负责拿 code，不做任何密钥运算 wx.login({ success: (res) => { // res.code 是临时凭证，交给后端换取 openid wx.request({ url: 'https://your-domain.com/api/auth/login', method: 'POST', data: { code: res.code }, success: (r) => { // 后端返回自定义 token，存起来供后续请求使用 wx.setStorageSync('token', r.data.token); } }); } });

这段代码的逻辑边界很清楚：小程序端只搬运 code，不碰 AppSecret，不解析 openid。参数上code是一次性凭证，后端换完就作废；token是后端签发的会话凭证，建议设 7 天有效期并支持刷新。答辩时如果被问「为什么不在前端换 openid」，答案就是密钥泄露风险。

2.2 Java 后端的分层：Controller、Service、Mapper 各管什么

后端用 Spring Boot 是当前最稳的选择，分层建议严格按 Controller → Service → Mapper 走。Controller 只做参数校验和响应封装，不写业务逻辑；Service 承载订单创建、库存扣减、状态流转这些核心逻辑，并且是加事务的地方；Mapper 用 MyBatis-Plus 操作数据库，单表 CRUD 基本不用手写 SQL。

答辩 PPT 里可以放一张分层调用图，配一句「所有写操作在 Service 层加@Transactional，保证订单和库存的一致性」。这里有个容易被追问的细节：@Transactional默认只对RuntimeException回滚，如果业务里抛的是受检异常，要显式写rollbackFor = Exception.class，否则事务不回滚，库存扣了订单没生成，这就是线上事故。

@Service public class OrderService { @Autowired private OrderMapper orderMapper; @Autowired private DishMapper dishMapper; // rollbackFor 必须显式声明，否则受检异常不回滚 @Transactional(rollbackFor = Exception.class) public Long createOrder(Long userId, List<OrderItem> items) { // 1. 先扣库存，扣减失败直接抛异常触发回滚 for (OrderItem item : items) { int affected = dishMapper.deductStock(item.getDishId(), item.getCount()); if (affected == 0) { throw new BizException("库存不足: " + item.getDishId()); } } // 2. 库存扣减成功后再落订单 Order order = buildOrder(userId, items); orderMapper.insert(order); return order.getId(); } }

逻辑说明：先扣库存再落订单，扣减用带条件的 UPDATE（stock >= count）保证原子性，返回影响行数为 0 说明库存不够。参数上deductStock的 SQL 必须写成UPDATE dish SET stock = stock - #{count} WHERE id = #{id} AND stock >= #{count}，靠数据库行锁防超卖，而不是先查再改——先查再改在并发下必然超卖，这是答辩必问的坑。

2.3 数据层选型：MySQL 存业务，Redis 顶热点

MySQL 存用户、菜品、订单、订单明细这些需要事务和持久化的数据。Redis 用来做两件事：一是购物车（用户加购频繁，写 MySQL 压力大），二是热点菜品的库存预扣（秒杀场景）。答辩 PPT 里可以画一条数据流：加购走 Redis Hash，下单时把 Redis 购物车落成订单明细。

订单状态建议用状态机管理，常见流转是：待支付 → 已支付 → 配送中 → 已完成，另有已取消分支。状态字段用整型枚举而不是字符串，方便索引和判断。这里给一张状态流转表，直接可以放进 PPT：

这张表的价值在于，答辩时老师问「订单超时没支付怎么办」，你能立刻答出「定时任务扫描待支付且超过 15 分钟的订单，置为已取消并回补库存」，而不是临场编。

3. 把核心功能做成可复现的代码：登录、下单、支付回调

架构讲完，答辩 PPT 的中间几页必须落到具体功能，否则全是空话。这一章挑三个最容易被追问、也最能体现技术含量的功能：微信登录换 openid、下单防超卖、支付回调验签。每个都给可抄的代码和参数说明，照着改就能跑。

3.1 微信登录换 openid：code 换 session 的完整链路

后端接收小程序传来的 code，调用微信的jscode2session接口换取 openid。注意这个接口的 URL 里带 AppID 和 AppSecret，必须放在后端，且建议把 AppID/AppSecret 放配置文件而不是硬编码。

@PostMapping("/api/auth/login") public Result login(@RequestBody LoginDTO dto) { // 拼接微信换取 openid 的请求，密钥从配置读取 String url = String.format( "https://api.weixin.qq.com/sns/jscode2session?appid=%s&secret=%s&js_code=%s&grant_type=authorization_code", appId, appSecret, dto.getCode()); String resp = restTemplate.getForObject(url, String.class); JSONObject json = JSON.parseObject(resp); String openid = json.getString("openid"); if (openid == null) { // 常见错误码 40029 code 无效、45011 频率限制 throw new BizException("登录失败: " + json.getString("errcode")); } // 查库或注册用户，签发自定义 token User user = userService.findOrCreateByOpenid(openid); String token = jwtUtil.sign(user.getId()); return Result.ok(Map.of("token", token)); }

逻辑说明：先拿 code 换 openid，换不到就按 errcode 报错。参数上grant_type固定为authorization_code；appId、appSecret从配置注入。常见错误码要能背出来：40029 是 code 无效（多半是重复使用），45011 是频率限制，-1 是系统繁忙。答辩被问「code 能重复用吗」，答「不能，一次性且五分钟过期」。

3.2 下单防超卖：条件 UPDATE 而不是先查后改

超卖是外卖、秒杀类项目的经典考点。错误做法是先SELECT stock判断再UPDATE，并发下两个请求都查到库存为 1，都去扣，结果扣成 -1。正确做法是把判断塞进 UPDATE 的 WHERE 条件，靠数据库的行锁保证原子性。

<!-- MyBatis-Plus 自定义 Mapper 方法，条件扣减库存 --> <update id="deductStock"> UPDATE dish SET stock = stock - #{count} WHERE id = #{dishId} AND stock >= #{count} </update>

逻辑说明：stock >= #{count}是防超卖的核心，只有库存足够时 UPDATE 才生效，返回影响行数。Service 层判断返回值为 0 就抛异常回滚。参数上count是购买数量，dishId是菜品主键。如果并发量再高，可以叠加 Redis 预扣：先在 Redis 里DECR判断，成功再落库，Redis 扣减用 Lua 脚本保证原子性。答辩时能说出「数据库条件更新兜底 + Redis 预扣削峰」两层，基本就稳了。

3.3 支付回调：验签、幂等、状态机三件套

微信支付回调是答辩里最能拉开差距的点。回调接口必须做三件事：验签（确认是微信发的）、幂等（同一笔回调可能重复到达）、状态机校验（只有待支付订单能改成已支付）。

@PostMapping("/api/pay/callback") public String payCallback(@RequestBody String body, @RequestHeader Map<String, String> headers) { // 1. 验签：用微信平台证书验证签名，失败直接拒绝 if (!wxPayService.verifySignature(headers, body)) { return "FAIL"; } JSONObject notify = JSON.parseObject(body); String orderNo = notify.getString("out_trade_no"); // 2. 幂等：加分布式锁或数据库唯一约束，防止重复处理 if (orderService.isPaid(orderNo)) { return "SUCCESS"; // 已处理过，直接返回成功 } // 3. 状态机：只有待支付订单才允许改为已支付 orderService.markPaid(orderNo, notify.getString("transaction_id")); return "SUCCESS"; }

逻辑说明：验签失败返回 FAIL，微信会重试；幂等判断防止重复加钱或重复发货；状态机保证非法流转被拦截。参数上out_trade_no是商户订单号，transaction_id是微信支付单号，两个都要存。返回SUCCESS微信才停止重试，返回其他内容会持续回调，这点答辩常被问。

4. 答辩 PPT 的页面组织：哪些内容必须上，哪些可以砍

技术讲清楚了，接下来是 PPT 本身怎么排。答辩时间通常 8 到 15 分钟，页数控制在 15 到 20 页比较稳。这一章给一套可直接套用的页面结构，并说明每页要放什么、老师可能问什么。

4.1 十五页结构：从选题背景到演示截图

建议的页面顺序是：选题背景与意义（1 页）、国内外现状（1 页）、技术选型（1 页）、系统架构图（1 页）、功能模块图（1 页）、数据库设计（1 到 2 页）、核心功能实现（3 到 4 页，对应上一章的登录、下单、支付）、难点与解决方案（1 页）、测试与演示（1 到 2 页）、总结与展望（1 页）。其中数据库设计和核心功能实现是重点，要留足页数。

数据库设计页不要贴整张 ER 图糊成一片，挑三到四张核心表讲清楚字段和关系即可。下面这张表可以直接放进 PPT：

字段设计里有两个答辩加分点：一是order_item里存下单时的单价快照，因为菜品价格会变，订单金额不能跟着变；二是order_no加唯一索引，配合支付回调幂等。

4.2 演示环节：本地跑通比截图更有说服力

答辩演示最忌讳只放静态截图，老师一句「你现场跑一下」就露馅。建议提前在本地把小程序和后端都跑起来，用微信开发者工具连本地后端（开发阶段可在开发者工具里勾选「不校验合法域名」）。演示路径走一遍：登录 → 浏览菜单 → 加购 → 下单 → 模拟支付回调 → 订单状态变化。

演示前一定要做的检查：后端服务是否启动、数据库连接是否正常、小程序请求域名是否配置、token 是否过期。这些细节翻车一次，答辩节奏就乱了。血泪经验是提前录一段演示视频兜底，现场网络或环境出问题时可以放视频，不至于冷场。

5. 答辩现场高频追问与避坑：这些坑我替你踩过了

技术做得再好，答不上追问照样扣分。这一章把答辩现场最常出现的坑按「现象 → 原因 → 解决」列出来，都是真实会被问到的。

5.1 避坑一：被问「你的项目有什么难点」答不上来

现象：老师问项目难点，回答「没什么难点，就是功能比较多」，直接暴露没深入思考。原因：只做了功能堆砌，没提炼技术问题。解决：提前准备两到三个有技术含量的难点，比如「下单并发下的超卖问题，用数据库条件更新 + Redis 预扣两层解决」「支付回调的幂等和验签」「订单超时取消的定时任务与库存回补」。每个难点讲清楚问题、方案、为什么这么选。

5.2 避坑二：数据库字段设计被追问就卡壳

现象：老师指着某张表问「这个字段为什么这么设计」，答不上来。原因：建表时照抄模板，没想过业务含义。解决：每张核心表都要能说出字段的业务来源。比如order_item的price是下单时的价格快照，不是当前菜品价格；orders的status用整型枚举，0 待支付 1 已支付 2 配送中 3 已完成 4 已取消，要能背出来。

5.3 避坑三：安全相关的问题一问三不知

现象：被问「AppSecret 放哪」「token 怎么防伪造」「支付回调怎么防伪造」，答得含糊。原因：只关注功能实现，忽略安全。解决：记住三条——AppSecret 只在后端、token 用 JWT 签名且设过期、支付回调必须验签。这三条能覆盖大部分安全追问。

5.4 避坑四：PPT 全是截图没有架构和数据流

现象：PPT 翻下来全是界面截图，老师看不出技术含量。原因：把答辩当产品展示。解决：至少放一张系统架构图、一张核心表设计、一段关键代码或流程图。架构图讲清三层分工，表设计讲清字段关系，代码讲清核心逻辑。

5.5 避坑五：演示环境当场崩

现象：现场演示时后端连不上、小程序报错、token 过期。原因：没做演示前检查，依赖现场网络。解决：提前跑通全流程，准备本地数据库和测试数据，录一段演示视频兜底，把「不校验合法域名」提前勾好。

6. 让答辩加分的一个技巧：用状态机把订单讲成一个故事

如果只让我留一个能让答辩明显加分的技巧，那就是把订单状态机讲成一个完整的故事，而不是零散地念功能。老师听了一整天「登录、下单、支付」，早就麻木了，但如果你能顺着一个订单的生命周期讲下来，他会觉得你真的理解业务。

具体做法是：在 PPT 里放一张订单状态流转图，然后现场用一句话串起来——「用户下单生成待支付订单，15 分钟未支付由定时任务取消并回补库存；支付成功后回调把订单置为已支付，商家接单进入配送中，用户确认后完成并触发评价」。这一句话里包含了定时任务、库存回补、支付回调、状态机四个技术点，信息密度高，还自然引出了后面的代码页。

状态机的实现建议用枚举加流转校验，而不是散落在各处的 if-else。下面这段代码可以直接用：

public enum OrderStatus { PENDING(0), PAID(1), DELIVERING(2), DONE(3), CANCELED(4); private final int code; OrderStatus(int code) { this.code = code; } // 定义合法流转，非法流转直接拒绝 public static boolean canTransfer(int from, int to) { if (from == PENDING.code && (to == PAID.code || to == CANCELED.code)) return true; if (from == PAID.code && to == DELIVERING.code) return true; if (from == DELIVERING.code && to == DONE.code) return true; return false; } }

逻辑说明：canTransfer把合法流转集中管理，任何状态变更前先校验，非法流转抛异常。参数上状态码和数据库存的整型一致，避免映射错乱。这样写的好处是，答辩时老师问「订单能从待支付直接跳到已完成吗」，你能立刻答「不能，状态机拦截了」，而不是含糊其辞。

验证方法也很简单：写一个单元测试，把每种流转组合跑一遍，断言非法流转返回 false。测试用例本身就是答辩材料，能证明你的状态机是经过验证的，不是拍脑袋写的。

我自己的习惯是，任何涉及状态的项目，先把状态机画出来再写代码，因为状态流转一旦漏了分支，后面全是补丁。答辩前把状态机图、核心代码、测试用例三样对齐，被问到任何订单相关问题都能顺着答下来。希望帮到你。

本文还有配套的精品资源，点击获取