自己完整做过的一个微信小程序毕业设计，项目代号就叫民大食堂，本质上是一个高校食堂用餐综合服务平台，交付物里包含完整源码、数据库设计和接口文档。它瞄准的场景很具体：学生到了饭点不知道哪个窗口人少、哪些菜已经卖完，高峰期排队浪费时间，商家也只能凭感觉准备菜量。如果你正在纠结毕设题目，或者已经选了小程序方向但不知道项目怎么从零搭起来，这篇内容应该能帮你省掉大量试错成本。先给结论：微信小程序加微信云开发，是我在毕设场景里反复验证过的性价比最高的组合。前端不需要买服务器，后端不需要考虑域名和备案，一个账号就能跑通登录、浏览菜品、加购、下单、模拟支付、商家接单、出餐叫号整个业务闭环，答辩演示效果非常完整。

1. 项目到底在做什么：需求拆解与功能规划

1.1 高校食堂的真实痛点，哪一条戳中了

食堂场景看起来很单纯，但把需求拆开看，问题还真不少。第一是高峰期的排队问题，下课时间集中，窗口前挤成一团，等餐二十分钟很常见。第二是信息不透明，进了食堂才知道哪个窗口人多、哪个菜卖完了，菜品图片和实际价格经常对不上。第三是部分校园食堂还停留在实体卡或纸质票据阶段，找零、丢卡都很麻烦。第四是商家侧没有数据意识，每天卖了多少、哪个菜受欢迎，全靠老板个人记忆。

这四个问题正好对应小程序的四个价值点：在线点餐降低排队决策成本、菜品图文展示消除信息差、订单记录和虚拟余额统一支付体验、商家统计看板提供营业参考。作为一个毕设项目，不需要真的解决食堂运营的所有问题，但要让评委看到你理解这些痛点，并给出了可落地的方案雏形，这就已经及格了。真正加分的地方在于，你能不能把痛点对应到具体的功能模块上，能不能解释清楚为什么这个功能能缓解那个问题。

1.2 功能模块划分：用户端、商家端、管理端

我按角色把系统分成了三层。用户端解决“吃什么、怎么快点吃上”的问题，功能包括菜品分类浏览、按窗口筛选、购物车管理、提交订单、订单状态跟踪、取餐码查看，以及个人中心里的历史订单和虚拟余额。商家端解决“怎么高效出餐、怎么知道卖得好不好”的问题，功能包括维护本窗口的菜品和价格、处理新订单、更新出餐状态、查看当日营业额和热销菜品排行。管理端在这个项目里作为补充，负责用户角色审核、菜品规范化管理和整体数据看板。

三个角色共用同一个小程序，登录之后根据 openid 对应的角色字段决定界面入口。这种设计在答辩时是加分项：你不需要安装第二套应用，只需要在用户端和商家端切换账号身份，就能把整条业务链路演示完，评委理解成本很低。当然这也带来了一个代价，前端要做好权限控制，非商家用户不能进入商家工作台，不能调用商家接口。权限控制这一块做得好不好，往往是区分普通毕设和优秀毕设的分水岭，后面我会专门讲实现方式。

1.3 需求优先级与 MVP 边界

毕设最怕需求越做越多，最后把自己拖垮。我当时给自己画了一条很清楚的 MVP 边界：第一版只做堂食点餐流程，不做外卖配送；支付用模拟支付，不接真实微信支付；叫号用取餐码加订阅消息，不做硬件叫号屏。有人会问，那还能叫“综合服务平台”吗？我认为完全可以。综合不一定是外卖加商城加跑腿那种大而全，而是核心链路完整：用户从打开小程序到浏览菜品、加购、下单、收到取餐通知，商家从接收订单、出餐到标记完成，这条路完整跑通，业务完整性就已经足够了。外卖、评价、餐补、拼单都可以放进后续规划，但绝不塞进第一版。

这个 MVP 思路会直接影响技术选型。因为不接真实支付，就不需要企业资质和商户号；因为不做外卖配送，就不需要地图定位和骑手调度模块。每砍掉一个需求，都是砍掉一个可能出 bug 的点，也砍掉一段写文档、画图、做测试的时间。很多同学项目烂尾，不是因为能力不够，而是第一版就背了太多不该背的功能。先让核心链路稳定跑通，再去谈更多可能性，这个顺序千万不能反。

2. 技术选型：怎样用最少成本搭出一套能答辩的完整系统

2.1 前端方案：原生小程序，别为了炫技强行上框架

前端我用的微信小程序原生语法，也就是 WXML、WXSS 和 JavaScript，没有引入 uni-app 或 Taro。理由有三：一是原生语法在微信开发者工具里调试最顺畅，报错直接定位，官方文档和社区案例也是最多的；二是毕设答辩经常被追问底层实现，用原生写出来的答案比“框架帮我们封装好了”硬气得多；三是如果组员没有 Vue 或 React 基础，原生写法几乎是零学习成本，协作起来更省心。我见过隔壁同学用 uni-app 做，结果打包配置来回折腾，编译报错处理就花了接近一周，反而把业务时间挤掉了。

原生小程序的页面结构其实很好理解，一个页面对应四个文件：wxml 管结构、wxss 管样式、js 管逻辑、json 管页面配置。放一起看就是一套很标准的 MVC 结构，导师听着也熟悉。只要把页面拆得够细，后续维护和写文档都会轻松很多。我这里页面拆分原则是：一个页面只干一件事，购物车页面不做菜品展示，订单列表页面不做支付操作，避免每个文件都变成几百行的大杂烩。

2.2 后端方案：微信云开发，绕开服务器和域名备案

后端选用微信云开发，这个选择基本决定了整个项目的开发速度。传统毕设要做后端，先买服务器，再买域名，然后备案，配 HTTPS，光是环境搭建可能就要一两周。学生机虽然便宜，但配置有限，答辩演示时访问量稍微上来就容易卡顿，场面非常尴尬。云开发把这些运维层面的问题直接抹掉了：云函数就是后端接口，云数据库就是数据存储，云存储就是图片服务，登录态还天然内置，甚至不需要自己写 token 校验。一个人开发毕设，省下来的时间可以全部投入到业务逻辑和文档写作上。

但这不意味着你可以完全不学后端知识。云函数里依然要写参数校验、状态机判断、数据一致性处理，这些东西和传统后端开发完全一样。我在项目文档里专门加了一段说明，把云开发和传统 Node.js 后端做了对比，核心结论是：云开发没有让你少学东西，只是把最繁琐的环境运维替你挡掉了。答辩遇到“你这个后端到底做了什么”的提问时，这套说辞很管用，既承认了云开发的便捷性，又强调了自己对服务端代码的掌控力。

2.3 数据库设计：四张核心集合，不多不少

云数据库是文档型数据库，不需要设计外键，也不用写 SQL，但设计仍然要做。项目里四张核心集合：users 存用户身份、角色和虚拟余额；dishes 存菜品名称、价格、图片、所属窗口、分类和库存；orders 存订单号、用户、窗口、菜品明细、金额、状态和取餐码；merchants 存窗口名称、归属商家、营业状态和公告。购物车数据我放在小程序本地缓存里，没有单独建集合，原因后面讲。

这些集合之间不需要物理外键，业务关联靠字段值自行对应。orders.windowId 指向 merchants._id，orders.userId 指向 users.openid。文档型数据库这种松散关联，在小程序和中小型项目场景里完全够用，查询也快。唯一要注意的是，如果数据量变大，记得给经常查询的字段建索引，比如 orders 里的 status、userId、createTime，否则数据一旦上千条，查询速度会明显下滑，答辩的时候翻订单列表卡住是很尴尬的。

2.4 接口设计：全部走向云函数，前端不碰数据库

很多小程序教程会教前端直接调用 db.collection().add() 或者 .get() 写数据，代码确实少，但危险也大。前端一旦直连数据库，权限管控基本失控，用户可以在开发者工具控制台里直接改集合内容，改余额、删订单、篡改菜品价格，什么都拦不住。我的做法是：所有读写操作都通过云函数完成，前端只调 wx.cloud.callFunction。每个业务动作独立成一个云函数，createOrder、updateOrder、getDishes、getOrders 等等。云函数内部做身份识别、参数校验、金额计算，再访问数据库，前端拿到的永远只是处理完的结果。

这个设计本身就是一套很标准的服务端接口规范。以后想换成 Java 后端或者 Node 后端，只需要把云函数内部的逻辑迁移过去，前端调用层几乎不用改。答辩被问到“前后端怎么分离”的时候，直接把这段讲出来，比空谈概念有力得多。实现细节上，我要求所有云函数返回统一格式：成功时返回 { code: 0, data: ... }，失败时返回 { code: -1, message: ... }，前端封装好统一解析，代码会干净很多。

3. 核心功能实现：从登录到取餐的完整闭环

3.1 登录与身份识别：为什么一定用 openid

小程序登录和传统网页登录完全不同。wx.login 拿到的 code 是一次性凭证，通过云函数可以换取 openid，这是微信用户在当前小程序下的唯一身份标识，不会变。有人会把头像昵称当登录凭证，这其实是个坑，用户改个昵称你就认不出来了。正确做法是：前端拿到 code 调 login 云函数，云函数用云端 SDK 解析出 openid，再查 users 集合，如果出现新用户就自动建一条默认记录，最后返回登录成功标记。前端拿到结果后再去拉用户资料，决定跳转到用户端还是商家端。

// cloudfunctions/login/index.js const cloud = require('wx-server-sdk') cloud.init({ env: cloud.DYNAMIC_CURRENT_ENV }) const db = cloud.database() exports.main = async () => { const { OPENID } = cloud.getWXContext() const users = db.collection('users') const existed = await users.where({ openid: OPENID }).get() if (existed.data.length === 0) { await users.add({ data: { openid: OPENID, role: 'user', nickname: '', avatar: '', balance: 0, createdAt: db.serverDate() } }) } return { code: 0, data: { openid: OPENID } } }

这里用 db.serverDate() 而不是前端传时间，是为了让时间以数据库服务器为准，避免用户伪造。这个细节虽然小，但答辩时被问到数据可靠性时可以直接拿来回答。另外，不要把 openid 打到前端日志里，控制台打印时注意脱敏，真机演示时这些信息可能被旁观的评委看到，提前养成好习惯总没有坏处。

3.2 菜品浏览与购物车：本地缓存带来的顺畅体验

菜品数据从 dishes 集合读取，首页按窗口分类加载。初次进入时加载当前窗口的菜品列表，之后用下拉刷新更新数据。菜品图片全部上传到云存储，数据库里只保存 fileID，前端用 image 组件直接渲染，省去了域名白名单配置的麻烦。购物车数据我直接存在本地，用 wx.setStorageSync 保存一个数组，每个元素包含菜品 id、名称、价格、图片和数量。这个设计有几个明显好处：加购响应零延迟、不消耗云函数调用次数、用户中途退出也不会丢购物车。

真正下单时，前端把购物车快照传给云函数，由服务端重新计算总价并校验菜品状态，前端传的价格只当作展示参考。这样就算有人改了本地缓存的价格，服务端也不会被欺骗。购物车不建集合、不下云端还有个好处，就是简化了数据库压力。食堂场景下一顿饭的购物车数据量其实很大，全部落库会白白增加集合体积，本地缓存对单个用户来说已经绰绰有余。

3.3 订单状态机：模拟支付也要有服务端校验

真实微信支付需要企业主体和商户号，个人主体小程序没有权限。毕设场景里最稳的做法是做一个模拟支付弹窗：用户提交订单后进入“待支付”状态，点击支付弹窗展示应付金额，确认后延时一秒模拟网络请求，然后调用云函数把订单状态改成“已支付·备餐中”。关键点在于：状态变更必须在云函数里发生，不能在前端直接 setData 完事。前端直接改状态，等于任何用户都能伪造支付成功。我在 updateOrder 云函数里会先判断订单当前状态，只有状态是“待支付”，才允许切到“已支付”。

为了实现严谨的流转，我定义了一整套订单状态机：

• 0 待支付：下单成功时生成
• 1 已支付 / 备餐中：模拟支付成功后由云函数迁移
• 2 待取餐：商家出餐后更新，触发取餐提醒
• 3 已完成：用户取餐或主动确认后结束
• 4 已取消：超时未支付自动取消，或用户主动取消

每次状态迁移都必须校验上一个状态。比如从 1 到 2 只有商家端能操作，从 2 到 3 用户端和商家端都可以。这个约束刚开始写起来有些啰嗦，但它恰恰保证了订单履历不会错乱。演示的时候让评委看到完整的状态流 0-1-2-3，每个节点都能在订单详情里留下记录，评委一眼就能明白业务流程是经过设计的。

3.4 商家端工作台：接单、出餐、核销取餐

商家端本质上是一个面向商家角色的小型管理后台。登录时识别 role 是 merchant，前端自动切换到工作台界面。窗口商家可以在菜品管理页上架、下架、改价格、调库存；订单页按状态分组展示属于自己窗口的订单，点击“接单”将状态从待支付改为备餐中，点击“出餐”改为待取餐并触发订阅消息；点击“完成”或等用户确认取餐后，状态变为已完成。取餐码在下单时就已经生成，订单卡片里高亮显示，方便窗口师傅快速核对。

商家端如果能加一个轻量统计看板，整个项目的信息量会非常饱满。我实现的是当日订单数、营业额、热销菜品 Top 5 三个指标，数据全部从 orders 集合里聚合而来。计算方式也很简单：按天过滤订单，把状态不为已取消的订单金额求和，再用 groupBy 菜品名称统计销量。这部分代码量不大，但体现了对业务数据的理解，答辩提问时素材会丰富很多。

3.5 取餐通知：订阅消息的申请时机很讲究

取餐提醒我用的是小程序订阅消息。原理很简单：用户授权后，服务端可以向用户下发一条一次性模板消息。但这里有一个常见坑，订阅消息的一次性授权只能用一次，如果用户在没有授权的情况下直接点击“提醒我”，云函数调用就会失败。所以正确的交互节奏是：在用户支付成功后的页面里，弹出一个订阅授权请求，用户同意后系统才有一次推送机会。不要把授权按钮放在最后一步，用户都快走完流程了，永远没有授权入口。

出餐时，云函数读取模板 ID 和用户 openid，调用云端的订阅消息接口，把窗口号和取餐码拼进模板内容。我在代码里用 try-catch 把推送失败吞掉，避免因为推送失败导致订单流程中断。这个细节讲解时很加分，因为小程序订阅消息机制和传统短信通知不同，很多第一次做的同学根本不知道还要区分授权次数，你主动讲出来，说明真的在微信生态里踩过坑。

4. 关键代码解析：这几个模块最体现工作量

4.1 封装云函数调用：少写几百行重复代码

页面调用云函数如果不做封装，业务代码里会散落大量 wx.cloud.callFunction，错误处理也会各写一套，风格很难统一。我抽了一个工具模块，把请求发送、状态码判断、错误提示统一收敛到一个文件里，页面只关心返回的数据，不需要关心网络层细节。这样每次新增页面，调用接口就是一行代码，格式也稳定。具体的封装代码长这样：

// utils/cloud.js const callFunction = (name, data = {}) => { return wx.cloud.callFunction({ name, data }).then(res => { const result = res.result || {} if (result.code !== 0) { throw new Error(result.message || '服务异常') } return result.data }).catch(err => { wx.showToast({ title: err.message || '网络异常', icon: 'none' }) return Promise.reject(err) }) } module.exports = { callFunction }

这套设计统一了云函数的返回格式：成功时返回 { code: 0, data: xxx }，失败时返回 { code: -1, message: '原因' }。页面像调用普通接口一样 await callFunction('getDishes', params)，代码清晰，也方便后期调整。如果以后要把后端迁移到自己的服务器，只需要改这一个工具函数，页面层逻辑几乎不用动，收益非常明显。这个小封装思路，放在简历里也可以作为工程化习惯的体现。

4.2 创建订单云函数：服务端才是算钱的地方

创建订单是业务逻辑最重的云函数，也是最值得写进论文设计部分的内容。用户从前端传来一个订单项数组，服务端要做的事包括：校验用户存在且状态正常；遍历订单项从 dishes 集合查出真实价格，重新计算总价，前端传的价格一律不信任；检查菜品 status 是否为上架中；判断是否超出每日份数限制；生成订单号和取餐码；写入 orders 集合并扣减库存。整个过程都在云函数内部完成，天然可以保持数据一致性。

// cloudfunctions/createOrder/index.js exports.main = async (event) => { const { OPENID } = cloud.getWXContext() const { items, paymentMode } = event if (!Array.isArray(items) || items.length === 0) { return { code: -1, message: '订单项不能为空' } } // 查询菜品真实数据 let total = 0 const orderItems = [] for (const item of items) { const dishRes = await db.collection('dishes').doc(item.dishId).get() const dish = dishRes.data if (!dish || dish.status !== 'on') { return { code: -1, message: `菜品${item.name}已下架` } } total += dish.price * item.count orderItems.push({ dishId: dish._id, name: dish.name, price: dish.price, count: item.count }) } // 生成订单号、取餐码 // 写入 orders 集合 return { code: 0, data: { orderNo, pickupCode, total } } }

订单号我用的格式是时间戳加四位随机数：Date.now() 拼接随机数，保证同一个人短时间内不会重复。取餐码按窗口维度生成，从 001 开始，每天从 1 重新计数。这里每次生成前会查一下该窗口当天的最大取餐码再加一，避免重复。代码逻辑不复杂，但体现了对业务唯一性约束的思考，属于答辩时可以直接被问到的技术点。

4.3 超时订单自动取消：定时触发器其实不难

订单如果不清理，数据库里会堆满“待支付”状态的记录，更重要的是这些订单会一直占住菜品库存。云开发提供的定时触发器可以让云函数按规则自动执行，做法是在云函数目录下放一个 config.json 文件，声明触发规则：

{ "triggers": [ { "name": "cancelOrderTimer", "type": "timer", "config": "0 * * * * * *" } ] }

注意这个表达式和 Linux cron 不一样，它是七段式：秒、分、时、日、月、星期、年。我写的 0 * * * * * * 表示每分钟的第 0 秒执行一次。云函数逻辑里查所有 status 为 0 且 createTime 距今超过 30 分钟的订单，批量把状态改成 4，同时回补库存。这个功能在答辩里非常涨分，因为它证明了你具备后台任务设计意识，不再只是写前端页面调接口，而是真的考虑了数据生命周期管理。

4.4 数据库权限设置：别在控制台开“所有人可读写”

云开发控制台默认的权限设置有时会让集合处于全公开状态。如果不改，相当于任何拿到 AppID 的人都可以在开发者工具里直接采集甚至改写集合内容。我的做法是把 users、orders 这类敏感集合全部设为“仅创建者可读写”，同时把核心业务读写全部收编到云函数。这样即使有人在前端尝试直连数据库，也会因为没有权限被拒绝。云函数访问数据库走的是服务端权限，不受集合权限限制，业务完全不受影响。

验收时我会特意打开云开发控制台的权限设置页面检查一遍，确保没有遗留开放读写的集合。很多项目平时能跑，一开演示就出异常，原因往往就在这个不起眼的地方。答辩前把这个点主动讲出来，评委的第一反应往往是：这个学生真的考虑过安全问题。哪怕只是毕设，拥有这种意识也是加分项。

5. 实操过程与避坑记录：调一个毕设到底要多久

5.1 三天跑通核心链路，真实时间表

在完整复现这个项目的过程中，核心链路我三天就完成了。第一天只做环境准备：注册测试号、安装微信开发者工具、开通云开发、创建一个空项目、跑通一个最简单的 login 云函数。第二天集中做数据层和页面：建集合、写菜品查询云函数、做菜品列表页和购物车页面。第三天专心磕订单流程：创建订单云函数、支付模拟、商家端状态切换、订单列表和取餐码展示。剩下时间全部花在页面样式调整、真机调试和文档写作上。如果不用云开发，这套链路光服务器环境准备可能就要一周。

这个时间表说明一个道理：毕设项目的进度瓶颈往往不是编码能力，而是环境问题和设计混乱。环境问题筛掉一波人，需求蔓延又筛掉一波人，真正专心写业务逻辑的时间其实很少。我把时间表写进文档，并且会用甘特图的形式给出整体计划，导师看项目计划书的时候会觉得你是有项目管理意识的，而不是那种拿到题目就埋头敲代码最后赶工的类型。

5.2 最容易踩的五个深坑

这五个坑是实际调试时真实遇到的，每一个都消耗过至少一晚上的时间。踩坑不可怕，可怕的是不知道坑在哪里，只能对着屏幕干瞪眼。

• 环境 ID 写错。wx.cloud.init 里的 env 不填或者填错，表现是本地模拟器能用、真机白屏。正确做法是在 app.js 里统一初始化，把环境 ID 抽到一个配置文件里，全局引用同一份。
• wx.login 的 code 过期。code 生命周期很短，前端不要长时间保存，正确做法是每次登录页面进入时重新调用 wx.login，实时换取新的 code。
• 定时触发器不运行。加了 config.json 后，还需要在开发者工具里重新部署云函数，只改代码不部署，触发器是不会生效的。部署后可以在云开发控制台看触发记录确认。
• 外链图片打不开。小程序对网络图片有域名白名单限制，与其去配置 downloadFile 合法域名，不如直接把菜品图传到云存储，用 fileID 换取临时链接显示。
• 用户连续点击重复下单。手速快的用户可以瞬间提交两笔一模一样的订单，前端按钮要做 loading 禁用，云函数里也要按用户和创建时间做一个简单查重，双保险才安全。

5.3 真机调试与账号状态的细节

模拟器里开发调试很方便，但真机上会有很多隐藏差异。第一，模拟器默认连接的环境可能和真机不同，如果真机取不到数据，第一步就检查 wx.cloud.init 的 env 配置。第二，本地缓存里的 userInfo 不能当登录凭证，用户换手机、清缓存之后仍然要靠 openid 去拉取用户资料，本地缓存只能用于提升启动速度。第三，真机的网络环境、字体渲染、键盘弹起都和模拟器有差异，菜品选择数量、提交订单这种高频操作要在真机上逐一测试。第四，订阅消息授权在模拟器和真机上的表现不完全一致，务必用真机验证推送链路。

我的习惯是准备两套测试方案：日常开发调试用模拟器，答辩演示前用真机完整跑一遍流程。期间顺手把 console 日志和网络请求记录截几张图，放到论文的测试章节里，既能证明测试工作量，又方便答辩时展示。真机调试踩过的每一个问题，都可以转化成论文里的“问题与解决方案”素材，不要浪费。

6. 常见问题速查表：答辩前最值得检查的十个点

把常见问题整理成一张速查表，是最实用的自查工具。很多项目平时跑得好好的，一到答辩现场就掉链子，问题的根源往往在配置、权限、状态管理这些细节上。我在项目文档最后附了这张表，每一次演示前都会照着走一遍，基本可以提前排除 90% 的现场故障。你也可以把它当作答辩前的最终检查清单来用。

如果项目在答辩现场真的白屏或报错，第一反应不是慌，而是看错误提示到底来自网络层、云函数层还是数据层。我习惯在云函数入口打印整个 event 和返回值，拿不到准确日志就开始瞎试，只会浪费时间。善用开发者工具的 Console 面板和云开发控制台的云函数日志，这两个工具能帮你解决绝大多数调试问题。日志打得好，排查问题速度至少快一倍。

7. 源码结构与二次开发指南

7.1 源码目录结构：先认文件夹，再改代码

很多同学拿到项目源码，第一反应是找入口文件直接改，其实目录结构本身就说明了项目设计思路。我在 README 里放了完整说明，这里给出大致结构：

miniprogram/ app.js # 全局逻辑，云开发初始化 app.json # 全局配置，页面路由 pages/ index/ # 首页 - 菜品列表 cart/ # 购物车 order/ # 订单确认与模拟支付 orders/ # 订单列表 detail/ # 订单详情 user/ # 个人中心 merchant/ # 商家工作台 admin/ # 管理端看板 utils/ cloud.js # 云函数调用封装 cart.js # 购物车本地管理 cloudfunctions/ login/ # 登录，返回 openid getDishes/ # 菜品列表 createOrder/ # 创建订单 updateOrder/ # 订单状态迁移 getOrders/ # 订单查询 cancelOrder/ # 超时关单（定时触发） getStats/ # 商家营业统计

看清结构之后，第一个要改的是 app.js 里的 cloud.init 环境 ID，第二个是全局配置，然后是各页面里属于自己的业务逻辑。不要一上来就把所有文件都打开看，而是先跑通一个最小链路：登录 -> 看菜单 -> 下单，再逐步深入其他模块。源码里我保留了一部分测试用的样例数据和注释，方便二次开发时对照理解每个函数的作用。

7.2 答辩演示脚本：5分钟讲完一个项目

答辩演示要有节奏，不能打开编辑器现场找页面。我习惯把演示分成四个环节：第一分钟，打开小程序首页，展示菜品分类和窗口信息，讲清楚这个项目解决什么问题；第二分钟，现场加几道菜进购物车、提交订单、走一遍模拟支付，重点展示订单状态从 0 到 1 的变化；第三分钟，切换到商家端，完成接单、出餐，展示取餐码生成和订阅消息触发，再把订单状态从 1 推到 2、3；第四分钟，打开订单列表和统计页面，说明数据都落到了云数据库，最后留时间回答提问。

演示过程中千万不要现场修改代码，更不要临时部署云函数。提前把账号、环境、网络、真机全部调试好，录一遍完整流程作为备份，防止现场意外。我还会准备一张纸，上面写清楚每个页面切换时对应的操作步骤和预期现象，真到紧张的时候照着念，效果比临场发挥稳定得多。这些细节看似琐碎，但在答辩现场能救命。

7.3 可扩展的方向：从毕设到真实产品还差什么

这个项目如果想做深，可以考虑几个方向。真实支付：注册企业主体小程序并申请微信支付商户号，把模拟支付替换成统一下单和回调处理，需要在云函数里配置支付回调地址，处理支付结果通知。扫码点餐：在每张桌子上放一个小程序码，用户扫码后自动带上桌号参数进入点餐流程，后厨可以按桌号合并订单。后厨联动：给后厨配一台展示当前待出餐订单的设备，商家工作台从手机端扩展到多端同步。校园餐补：对接学校的统一身份认证和余额系统，把虚拟余额替换成真实余额账户。

毕设阶段把这些内容列在“后续规划”文档里，论文里作为展望章节，会显得你考虑问题很系统。面试的时候如果被问到项目挑战，也可以直接说：我已经想清楚了模拟支付和真实支付的差别，以及接入商户号后的回调处理方案。哪怕暂时没做真实支付，能讲清楚差距也是一种能力展示，比单纯说“毕设项目”四个字有说服力得多。

最后分享一点个人体会。这个项目让我收获最大的，不是某一门具体技术，而是对“闭环”两个字越来越敏感。用户下单、商家接单、状态流转、数据入库，看起来简单，但每一步细节里都藏着工程问题。我自己最狼狈的一次，是订单状态在不同设备上显示不一致，用户端显示已完成，商家端还停在待取餐，排查到最后发现是服务端少了状态校验。从那天起，我写任何后端逻辑都习惯先查当前状态再改新状态，这个习惯一直用到现在。希望这份内容能帮你避开这些坑，把毕设做得扎实一点。源代码结构如果整理得好，把它改造成自己学校食堂的系统，也就是换几个字段名的事。