企业官网建设流程全解析

去年做毕设辅导的时候，我发现"基于微信小程序实现订餐管理系统"这个题目几乎成了烂大街的代名词。GitHub上和各类资源站里，这类项目源码少说也有几十套，九成是同一套模板换皮——菜品列表、购物车、提交订单、后台管理，界面乍一看都像那么回事，可真被问到"订单状态怎么流转""并发下单时库存怎么保证不超卖""金额为什么不能用浮点数存"，很多人就卡壳了。这篇文章我不想再复述一遍那种"能跑就行"的demo思路，而是把这套订餐管理系统的完整落地过程拆开聊一聊：从需求边界、技术选型、数据库设计，到核心链路实现、管理后台的取舍，再到论文说明怎么写才经得起答辩追问。如果你目前正在搞类似的毕设、课设，或者只是想自己动手做一个能拿得出手的小程序项目，这篇内容应该能帮你少走不少弯路。

1. 立项之前：先想清楚这个订餐系统是给谁用的

很多同学拿到题目就急着开写，打开微信开发者工具先搭界面，结果做到一半发现这里缺个角色、那里少个流程，回头改数据库改到崩溃。我习惯在写第一行代码之前，先花半天时间把"这个系统到底服务谁"这个问题彻底想明白。

1.1 用户是谁，在什么场景下打开这个小程序

订餐管理系统的使用场景其实包含两类完全不同的角色。第一类是顾客，他们的诉求很简单：打开小程序能看到今天的菜品，挑几样加进购物车，下单后等着商家接单出餐。第二类是商家或者餐厅管理员，他们不太会一直盯着手机屏幕，更多时候是在电脑上打开管理后台，处理新订单、上下架菜品、查看今天的营业数据。

如果你把这两类角色的需求混在一起设计，最容易出现的毛病就是：小程序端塞了一堆只有管理员才用得上的功能，比如"菜品管理""订单报表"，导致顾客界面臃肿；或者管理后台做得跟顾客端一样花哨，却没抓住"处理订单"这个核心动作。我的建议是：从一开始就把前端小程序和管理后台拆成两个独立项目，小程序它只为顾客服务，后台管理页面才是给商家用的。

1.2 两类角色的核心任务清单

我给自己整理过一张任务清单，现在分享出来，做同类型项目时可以直接参考：

顾客端（微信小程序）：

• 浏览菜品列表，按分类筛选（热菜、凉菜、主食、饮品等）
• 查看菜品详情，包括图片、价格、销量、简介
• 维护购物车，支持加菜、减菜、清空
• 提交订单，填写用餐人数、备注，选择取餐/配送方式
• 查看订单状态（待接单、制作中、待取餐、已完成、已取消）
• 个人中心页面，管理收货信息、查看历史订单

商家端（Web管理后台）：

• 菜品管理：新增、编辑、上下架、调整分类
• 订单管理：接单、出餐、完成订单，能看到订单明细
• 基础统计：今日订单数、营业额、菜品销量排行

这套配置已经覆盖了"订餐管理"的核心闭环。至于营销活动、优惠券、会员积分这类功能，我建议先砍掉，除非你的题目明确要求，否则做出来既增加开发量，又容易在论文里说不清楚。一个边界清晰、闭环完整的小系统，远比一个功能堆砌但逻辑混乱的大杂烩更值得写进论文。

1.3 MVP功能边界：哪些必须做，哪些可以砍

我见过不少人在这种项目上翻车的共同原因，就是把范围铺得太大。比如非要做"用户端在线支付""骑手配送轨迹""优惠券满减"，结果微信支付需要企业资质、配送轨迹需要地图SDK、优惠券涉及复杂的金额分摊逻辑，任何一个都够折腾好几周。如果你现在也卡在"功能太多做不完"，我给的建议是：

• 必须保留：菜品浏览、购物车、下单、订单状态流转、后台菜品管理、后台订单处理。这六件事构成了订餐系统的基本闭环。
• 可以简化：支付环节用"模拟支付"或"到店支付"替代，在论文里注明这是为了规避个人主体无法开通微信支付的问题。
• 绝对砍掉：会员体系、积分商城、实时配送跟踪、多门店连锁。这些听起来很加分，但实际上每一项都引入一个新领域，对毕设而言性价比太低。

等基础闭环跑通之后，如果你还有余力，优先加"数据统计报表"而不是"花哨动画界面"，因为前者在论文中可以做可视化展示，还容易引出分析结论。

2. 技术选型：原生小程序、uni-app和后端框架怎么选

这个项目最核心的技术选型有两个：小程序前端到底用原生还是uni-app，后端到底是自建服务器还是用云开发。这两个决定会直接影响你的开发效率、论文篇幅和答辩深度。

2.1 前端三选一：原生、uni-app、Taro

先排除Taro，它适合本身精通React的开发者，对大部分做毕设的人来说学习成本不划算。剩下原生小程序和uni-app，我给你一个很实在的建议：如果这个项目的预期用户只跑在微信里，而且你不想额外折腾，选原生微信小程序就对了。

原生小程序的优点在于：微信开发者工具一站式搞定，调试方便，组件和API文档最全，遇到问题搜索出来的解决方案绝大多数也是针对原生写的。uni-app的优势是一套代码可以同时发布到微信、支付宝、百度小程序和App，但代价是你要多学一层框架的语法规则，而且一旦遇到平台差异（比如某个API在微信端和小程序端的表现不一致），排查起来比原生麻烦得多。

从论文的角度看，写"基于微信小程序原生开发"会让你少很多解释成本。如果你论文里写"基于uni-app跨端框架"，那答辩老师很可能追问一句"你为什么不用原生"——你需要准备一套有说服力的理由，而"为了以后能发布到App"这种回答其实挺虚的，因为你的毕业设计根本不会真的去上架App。

2.2 后端与数据库：自建服务器还是微信云开发

这是另一个容易纠结的点。目前做微信小程序项目，后端路线基本有两种：

第一种是传统自建后端，比如Java Spring Boot、Node.js Express或者Python Flask，再配一个MySQL数据库。这种方案的好处是技术栈经典、面试/答辩时技术含量高，"我对订单做了事务处理""我用Redis做了缓存"这些话很有分量；坏处是环境配置繁琐，部署需要一台云服务器，前后端联调要处理跨域、鉴权、接口文档一堆事。

第二种是微信云开发（云函数 + 云数据库 + 云存储），不用自己买服务器，直接在微信开发者工具里写云函数，数据库是文档型的（类似MongoDB）。这个方案的上手难度真的低，开发速度非常快，适合时间和精力有限的人。但它的短板也很明显：云函数的执行环境对事务支持有限，你要做库存扣减这类需要原子性的操作时，应对手段比MySQL要绕一些；而且论文里的"数据库设计"如果只是几张JSON格式的集合，说服力会弱不少。

我的实际建议是：如果你本身有后端基础，或者答辩要求偏传统软件工程，就选自建后端 + MySQL；如果你几乎没写过后端、时间又紧，云开发是保命选项。但我见过更多的情况是，选了云开发的人最后在论文里花了一整章解释云函数，反而把业务逻辑给写薄了。这不算错，只是你要想清楚自己答辩更想展示哪一面。

2.3 项目整体目录结构参考

不管选哪条后端路线，前后端分离的项目结构我建议这样组织：

ordering-system/ ├── miniprogram/ # 微信小程序前端 │ ├── pages/ │ │ ├── index/ # 首页：菜品列表 │ │ ├── category/ # 分类页（可与首页合并） │ │ ├── cart/ # 购物车页 │ │ ├── order/ # 订单列表 │ │ ├── order-detail/ # 订单详情 │ │ └── mine/ # 个人中心 │ ├── components/ # 通用组件（菜品卡片、数量选择器） │ ├── utils/request.js # 封装wx.request │ └── app.js / app.json # 全局逻辑与配置文件 ├── admin-web/ # 管理后台（Vue或原生H5） │ ├── src/views/ │ │ ├── login.vue │ │ ├── dashboard.vue │ │ ├── dish-list.vue │ │ └── order-list.vue │ └── src/api/ ├── server/ # 后端服务 │ ├── controllers/ │ ├── services/ │ ├── models/ │ └── routes/ └── db/ # 数据库脚本

这个结构最大的好处是前端、后台、后端、数据库各占一块，对应到论文里刚好是几个独立章节，每一部分都有东西可写，不至于让论文变成一张架构图加一堆代码截图。

3. 数据库设计：一张订单表如何撑起整个订餐闭环

后台选什么框架可以各有偏好，但数据库设计的核心思路是相通的。订餐管理系统本质上是一个典型的"进销存 + 交易"场景，表结构设计得好，后面写代码会非常顺畅；设计得不好，光改字段就能让你崩溃。下面说一套我验证过多次的表结构。

3.1 核心表：用户、菜品、分类、购物车、订单、订单明细

先看建表SQL，我用的是最常用的MySQL写法，大家根据自己的数据库类型调整即可：

-- 用户表 CREATE TABLE `user` ( `id` INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, `openid` VARCHAR(64) NOT NULL COMMENT '微信openid，唯一', `nickname` VARCHAR(50) DEFAULT '', `avatar` VARCHAR(255) DEFAULT '', `phone` VARCHAR(20) DEFAULT '', `role` TINYINT NOT NULL DEFAULT 0 COMMENT '0-顾客 1-管理员', `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 菜品分类表 CREATE TABLE `category` ( `id` INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, `name` VARCHAR(30) NOT NULL, `sort` INT DEFAULT 0 COMMENT '排序权重', `status` TINYINT NOT NULL DEFAULT 1 COMMENT '1-显示 0-隐藏' ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 菜品表 CREATE TABLE `dish` ( `id` INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, `category_id` INT NOT NULL, `name` VARCHAR(50) NOT NULL, `price` DECIMAL(10,2) NOT NULL COMMENT '单价，注意DECIMAL', `image` VARCHAR(255) DEFAULT '', `description` VARCHAR(255) DEFAULT '', `stock` INT NOT NULL DEFAULT 0 COMMENT '剩余库存', `status` TINYINT NOT NULL DEFAULT 1 COMMENT '1-在售 0-下架', `sales` INT NOT NULL DEFAULT 0 COMMENT '销量', `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 购物车表 CREATE TABLE `cart` ( `id` INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, `user_id` INT NOT NULL, `dish_id` INT NOT NULL, `quantity` INT NOT NULL DEFAULT 1, `selected` TINYINT DEFAULT 1, `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY `uk_user_dish` (`user_id`, `dish_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 订单表 CREATE TABLE `orders` ( `id` INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, `order_no` VARCHAR(32) NOT NULL COMMENT '业务订单号', `user_id` INT NOT NULL, `total_amount` DECIMAL(10,2) NOT NULL, `status` TINYINT NOT NULL DEFAULT 0 COMMENT '0-待接单 1-制作中 2-待取餐 3-已完成 4-已取消', `remark` VARCHAR(255) DEFAULT '' COMMENT '用户备注', `take_type` TINYINT DEFAULT 0 COMMENT '0-到店取 1-配送', `address` VARCHAR(255) DEFAULT '' COMMENT '配送地址', `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP, `update_time` DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 订单明细表 CREATE TABLE `order_item` ( `id` INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, `order_id` INT NOT NULL, `dish_id` INT NOT NULL, `dish_name` VARCHAR(50) NOT NULL, `price` DECIMAL(10,2) NOT NULL, `quantity` INT NOT NULL, `subtotal` DECIMAL(10,2) NOT NULL ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这几张表已经能满足顾客端和管理端绝大部分功能。注意几个关键细节：第1节提到的"角色"字段，直接放在user表里用role表示；openid是一对一的唯一标识，用它关联微信登录用户；dish表的stock字段用于后续库存控制；orders和order_item是典型的一对多主从表关系。

3.2 为什么要单独拆一张订单明细表

这是我在指导项目时必问的一个问题，也是答辩时容易翻车的地方。一个订单可能包含多道菜，如果只往订单表里塞一个dishes字段，用逗号分隔菜品ID，那后续查"某道菜一共卖了多少"、统计营业额、给用户展示订单详情，全都会变成噩梦般的字符串解析。所以必须拆出order_item表，让每个订单对应多条明细记录，每条记录单独存菜品名、单价、数量和小计。

这里有一个看似简单但很多人忽略的问题：order_item里存的菜品名和价格，应该是下单那一刻的快照，而不是直接引用dish表的当前值。因为商家完全可能在下单之后修改菜名或价格，如果订单明细跟着变了，那历史订单的数据就失真了。这一点在论文的数据库设计章节里写出来会很加分，说明你真的理解"数据快照"的意义。

3.3 状态字段的设计：用数字、字符串还是枚举

订单状态status字段我习惯用数字0/1/2/3/4，在代码里用常量定义，而不是直接存"待接单""制作中"这样的中文。这么做的好处有三个：一是数据库存储更紧凑，二是排序和比较更高效，三是用数字可以非常方便地做状态机控制，比如"只有待接单状态才能被接单""已完成订单不允许取消"这类约束，用数字范围判断就很简单。

要注意的是，数字状态对后来的维护者并不友好，所以我的做法是在代码里集中定义常量并在注释里写明每个数字的含义，或者建一张字典表。比如此项目我会在service层这样写：

const OrderStatus = { PENDING: 0, // 待接单 PREPARING: 1, // 制作中 READY: 2, // 待取餐 DONE: 3, // 已完成 CANCELED: 4 // 已取消 };

所有用到状态判断的地方都引用这个常量，而不是直接写魔法数字。这样既保留了数字存储的效率，又避免了后续改代码时看不懂"4"是什么意思。

4. 核心链路实现：从顾客点餐到商家出餐的完整逻辑

数据库设计完之后，就是整个项目最核心的部分：业务链路的实现。我按照一套典型的订餐流程来拆解：顾客进入小程序浏览菜品、加购物车、提交订单，商家在后台看到新订单并处理。

4.1 小程序端的页面组织与tabBar设计

微信小程序的pages目录结构直接影响开发效率和用户体验。这个项目我建议tabBar设置三个入口：

• 首页（index）：菜品分类 + 菜品列表，顶部放一个横向滚动的分类导航栏，下面展示菜品卡片
• 订单（order）：订单列表，按状态筛选；点进去看订单详情
• 我的（mine）：用户信息、配送地址、联系客服等入口

购物车不单独占一个tabBar位置，而是用首页右下角浮动按钮或者顶部购物车图标进入，因为购物车本质上是一个临时容器，单独占一个tab页会显得内容太少。这个细节在答辩时被问"为什么这样设计"的话，你可以从用户体验和信息架构的角度回答。

小程序端的核心交互是"加购物车"和"提交订单"。加购物车我建议用本地缓存结合接口同步的方式：用户点"加入"时，先把菜品写入本地storage，提升响应速度，同时异步调用后端接口把购物车数据同步到服务端。这样即使顾客中途退出小程序，重新进来购物车数据也不会丢。但如果你的后端用了云开发，直接每次操作都调数据库问题也不大，本地缓存方案更像是一个优化思路，可以写进论文的"性能优化"部分。

4.2 购物车状态管理：本地缓存与服务端同步

购物车这个模块看着简单，但实现上有个容易踩坑的点：并发和一致性问题。用户在页面上快速加减菜品，如果每次都实时请求后端，网络延迟会导致购物车数字闪烁甚至错乱；如果只改本地缓存，又可能丢失数据。

我的方案是双写，但有一个更新顺序：本地先更新，界面立刻响应，然后异步同步到后端。同步接口设计成批量模式，一次提交整个购物车列表，而不是单个菜品增减，这样避免频繁请求。同时后端接口要做幂等处理——同样的请求发两次，最终购物车数据应该是一样的，这可以靠user_id + dish_id唯一键配合INSERT ... ON DUPLICATE KEY UPDATE来实现。

// 购物车同步核心逻辑，简化版 async function syncCart(items) { const res = await request('/api/cart/sync', { method: 'POST', data: { items } }); // 服务端按 user_id + dish_id 做 upsert， // 对每个 item 执行： // INSERT INTO cart (user_id, dish_id, quantity) VALUES (?, ?, ?) // ON DUPLICATE KEY UPDATE quantity = VALUES(quantity) }

这段代码的关键点是：不要把"加购物车"和"改购物车"拆成不同接口，统一用sync全量同步，逻辑简单且不易出错。

4.3 下单接口：库存扣减、金额计算的原子性

下单是最容易出bug的环节。很多人写的时候没想过：两个顾客同时下单，最后一个库存的菜品被两个人同时抢到了，怎么办？我在这类项目中一定会要求核心下单逻辑满足"库存扣减和订单生成要么同时成功，要么同时失败"，用MySQL事务就能解决这个问题。

下订单的伪代码逻辑大致是这样：

async function createOrder(userId, items, remark, takeType) { const conn = await db.getConnection(); try { await conn.beginTransaction(); // 1. 计算总金额，同时锁定菜品库存行 let total = 0; for (const item of items) { const rows = await conn.query( 'SELECT price, stock FROM dish WHERE id = ? FOR UPDATE', [item.dishId] ); if (!rows.length || rows[0].stock < item.quantity) { throw new Error('菜品库存不足'); } total += rows[0].price * item.quantity; } // 2. 扣减库存（注意用条件更新防止超卖） for (const item of items) { const result = await conn.query( 'UPDATE dish SET stock = stock - ? WHERE id = ? AND stock >= ?', [item.quantity, item.dishId, item.quantity] ); if (result.affectedRows === 0) { throw new Error('库存不足'); } } // 3. 生成订单主表和明细表 const orderNo = generateOrderNo(); const orderId = await conn.query( 'INSERT INTO orders (order_no, user_id, total_amount, status, remark, take_type) VALUES (?, ?, ?, 0, ?, ?)', [orderNo, userId, total, remark, takeType] ); for (const item of items) { await conn.query( 'INSERT INTO order_item (order_id, dish_id, dish_name, price, quantity, subtotal) VALUES (?, ?, ?, ?, ?, ?)', [orderId, item.dishId, item.dishName, item.price, item.quantity, item.price * item.quantity] ); } // 4. 清空购物车中已下单的菜品 await conn.query('DELETE FROM cart WHERE user_id = ? AND dish_id IN (?)', [userId, items.map(i => i.dishId)]); await conn.commit(); return { orderId, orderNo, total }; } catch (err) { await conn.rollback(); throw err; } }

注意几个细节：SELECT ... FOR UPDATE是行级锁，防止两个事务同时读到同一个库存；UPDATE ... WHERE stock >= ?是乐观条件更新，进一步兜底；订单号和订单明细都要在同一个事务里写入。这一套逻辑放到论文里是妥妥的一个亮点，答辩老师说"你怎么解决并发超卖"，你直接把这个事务过程描述出来即可。

4.4 订单状态机流转与用户感知

订单状态是典型的有限状态机，我在代码里把它封装成一个独立模块，避免出现"从已完成改成待接单"这种非法跳转。合法的状态转移是：

• 待接单（0）：可被商家接单 -> 进入制作中；顾客也可以取消 -> 已取消
• 制作中（1）：出餐后 -> 待取餐
• 待取餐（2）：顾客确认取餐 -> 已完成
• 已完成（3）：终态，不可再修改
• 已取消（4）：终态，只在待接单时可触发

我建议在服务端对状态流转做严格校验，而不是只在前端根据按钮显隐来控制。比如后端接口/api/order/status接收orderId和targetStatus，服务端先查出当前状态，判断转移是否合法，不合法直接返回错误。前端只管发请求，所有的业务规则都在服务端约束，这样即使有人绕过前端直接调接口也钻不了空子。

顾客端对订单状态的感知，主要通过订单列表页和订单详情页展示。可以给状态加一个简单的时间线组件：客户下单时间、商家接单时间、出餐时间、完成时间，这些时间字段可以在订单主表里用accept_time、finish_time等冗余字段记录，方便展示和统计。再次强调，这种"时间线"看起来是个小功能，但在论文的测试截图里非常加分，因为它直观体现了整个流程闭环已经打通。

5. 管理后台的最小可用版本：不要把它做成第二个小程序

管理后台是整个系统里最容易做过头或者做不足的部分。做过头是指你花大量时间给它配上漂亮的仪表盘、数据图表、权限管理；做不足是指你只给了一个一眼假的静态页面。实际上，对于订餐管理系统的毕设来说，一个"能真实操作、能跑通流程"的简洁后台就够了。

5.1 管理后台功能清单：菜品上下架与订单处理

我给管理后台定了三个核心页面：数据概览、菜品管理、订单管理。

数据概览页展示今天、本周、本月的订单数和营业额，以及菜品销量Top5，用简单的柱状图或排名列表显示即可。菜品管理页支持新增菜品、编辑信息、调整价格、上传图片，一键上架/下架。订单管理页按照订单状态Tab分组，待接单的订单最好有红色角标提示，商家点击接单后订单状态变为制作中，然后可以继续操作到出餐、完成。

这里有一个容易被忽略的体验问题：管理后台往往是商家在电脑上用的，所以你布局上要适配PC屏幕，不要做成手机版式拉宽了事。如果管理后台是Vue项目，用Element Plus或Ant Design Vue组件库，能省掉大量的样式时间。

5.2 管理员身份的区分方案：不止是前端隐藏入口

安全问题很多同学做得其实很薄弱。常见做法是前端判断用户是不是管理员，是就显示后台入口，不是就隐藏。但这个完全不够，因为接口是可被直接调用的。正确的做法是后端在做权限校验时，不仅仅依赖前端传来的role字段，而是从登录态中获取到安全可信的身份标识。

具体到微信小程序项目，用户登录时后端通过code换取的openid查出该用户，再判断role字段是否是管理员。所有的管理接口都要经过一个"管理员校验中间件"，比如：

async function adminGuard(req, res, next) { const user = await getUserFromSession(req); if (!user || user.role !== 1) { return res.status(403).json({ message: '无权限访问' }); } next(); }

这样即使用户篡改前端请求参数，把role改成管理员，也无法访问管理接口，因为服务端认的是openid对应的数据库记录，而不是请求参数。这个点一定要写进论文的"系统安全设计"章节，很能体现工程意识。

另外，管理后台的登录建议不要直接用微信扫一扫授权，而是单独用账号+密码的方式登录，后台管理员账号由系统初始化时写入数据库。这样可以避免"顾客小程序和管理后台共用同一套登录逻辑"带来的复杂度。

5.3 数据统计的简单实现思路

统计功能不需要引入重型BI工具。营业额、订单数这类指标，直接用SQL聚合查询即可。比如今日营业额：

SELECT IFNULL(SUM(total_amount), 0) FROM orders WHERE status IN (1, 2, 3) AND create_time >= CURDATE();

菜品销量排行：

SELECT dish_name, SUM(quantity) AS total_sales FROM order_item GROUP BY dish_name ORDER BY total_sales DESC LIMIT 5;

这两条SQL已经能支撑管理后台概览页的数据需求。性能上不用太担心，订单量级在毕设范围内完全扛得住。真到了需要优化的时候，再加缓存和索引不迟。

6. 实测中崩过三次的地方：登录态、精度与并发

这一节我想把项目调试过程中真正让人头疼的三类问题摊开来讲。这些问题在网上随便搜都能搜到答案，但只有自己踩过一遍，才会真正理解背后的原理。

6.1 登录态失效：wx.login的code与session_key

微信小程序的登录流程是：前端调用wx.login拿到临时code，把code发给后端，后端拿着code去微信接口换取openid和session_key，然后后端自己生成一个自定义登录态（比如token）返回给前端。前端之后每次请求都带上token，后端通过token识别用户。

我在第一次做的时候犯过一个低级错误：把session_key当成用户登录态返回给前端，然后前端每次请求都带着session_key。这种做法有两个问题：session_key是微信端的会话密钥，设计上不应该暴露给客户端；而且微信的session_key有效期很短，过期后用户就"被登出"了。正确做法是后端生成自己的token，比如随机字符串或者JWT，把openid和role信息绑定在token上，并设置合理的过期时间（一般7天或30天）。

还要注意token刷新策略。小程序前端在请求时遇到401，不应该直接让用户重新登录，而是静默用wx.login获取新code去换新token，然后重放原请求。这样体验比较好。这个"静默刷新"的逻辑可以封装在utils/request.js里，所有请求统一走同一套逻辑。

6.2 金额精度：为什么数据库必须用DECIMAL

这是另一个典型错误。第一次写后端时，我图省事把菜品单价和订单金额定义成DOUBLE，两个小数一乘，小数的二进制误差就开始显现了，比如0.29 * 3算出来的结果可能是0.8700000000000001。虽然展示时四舍五入能遮住，但一旦涉及统计求和、报表展示，累计误差会让人非常头疼。

解决办法就一条：金额永远不要用浮点类型。数据库用DECIMAL(10,2)，后端语言里如果有大数类型就用大数类型，比如Java的BigDecimal；如果用的是JavaScript，前端展示虽然用Number没问题，但后端涉及到金额计算时要格外小心，最好用整数以"分"为单位运算，最后再转成"元"展示。

举个例子：你收到的接口返回可能是price: 19.90，但后端从数据库读出来的是整数1990（分），在传给前端之前除以100转成字符串或数字，前端展示时再格式化。这个小细节在答辩时很能说明问题。

6.3 并发下单：库存超卖是如何发生的

"超卖"问题前面在事务那节提过一次，但这里我想还原一次真实的bug现场。我早前用云开发做课程设计时，下单逻辑是先查库存、再判断、再扣库存，三步是分离的：

// 错误示例 const dish = await db.collection('dish').doc(dishId).get(); if (dish.stock < quantity) throw new Error('库存不足'); await db.collection('dish').doc(dishId).update({ stock: dish.stock - quantity });

这个逻辑单测没问题，但两个用户同时下单时，两个请求都读到库存=1，都判断库存充足，然后都去减库存，最后库存变成-1，这单还是卖出去了。在传统MySQL下用事务可以解决，在云开发里则要用"原子操作"或"事务"，比如云数据库的inc指令是原子的：

// 云开发正确示例 const result = await db.collection('dish').doc(dishId).update({ stock: db.command.inc(-quantity) });

但仅靠inc还不够，因为库存可能被减成负数。需要先查询库存是否充足，再通过update({ stock: _.inc(-quantity) })，中间依然有竞态。最稳妥是靠数据库事务，或者通过条件更新语法确保stock >= quantity才更新。不管用哪种方案，都要把"防止超卖"的机制写清楚，这个问题是答辩时的高频考点。

7. 从项目源码到论文说明：如何把做的东西整理成高分材料

最后这部分，我想专门聊聊"论文说明"。这个题目自带"【项目源码+论文说明】"的标签，很多人以为论文就是把代码抄一遍、截图贴上去，其实完全不是。导师和评阅老师更希望看到的，是你对需求、设计、实现、测试这一整套工程方法论的掌握。

7.1 论文结构建议：一条主线贯穿始终

我给这个题目推荐一个论文大纲，大家可以按需调整：

1. 绪论：研究背景与意义、国内外研究现状、论文主要内容与章节安排
2. 相关技术介绍：微信小程序开发框架、后端框架、MySQL数据库、前后端交互机制
3. 系统分析：可行性分析、功能需求分析、非功能需求分析、用例图
4. 系统设计：总体架构、功能模块设计、数据库设计（ER图 + 表结构说明）
5. 系统实现：分模块展示关键代码与运行截图，最好配合核心逻辑的文字说明
6. 系统测试：测试环境、功能测试用例表、测试结果分析
7. 总结与展望：总结工作，指出不足与改进方向

关键在于"系统设计"和"系统实现"这两章，一定要做到前后呼应。设计章节里的数据库表、模块划分，在实现章节里都应该能找到对应的代码页面，不要设计一套、实现一套。写论文时最怕的就是两张皮——设计图画得漂漂亮亮，代码里完全是另一回事，导师一追问就露馅。

7.2 写论文时容易忽略但在答辩时被追问的点

• 为什么这个接口要设计成POST而不是GET？如果讲不出HTTP语义，至少要有接口层面的安全意识。
• 密码和token怎么存储和传输？不要在论文里贴出把token写在localStorage的代码，更不要把数据库密码写在配置文件里。哪怕只是毕设，也要体现基本的安全意识。
• 订单号用什么策略生成？我在项目里用了"时间戳+随机数"的生成方式，避免用自增主键当订单号暴露给用户，这会泄露业务量。
• 测试数据是怎么造的？不要只在论文里写"测试结果全部通过"，最好附上测试用例表，包括正常的点餐流程、库存不足流程、取消订单流程、管理员登录流程等。

我个人还建议在论文的"系统测试"部分加入一些边界条件的测试，比如：当购物车为空时提交订单会怎样？当菜品已下架但仍在购物车里会怎样？这些细节会让评阅老师觉得你不是在应付，而是真的做了完整验证。

7.3 如何给源码配一份"能看懂"的说明文档

很多项目源码下载之后是一堆代码，没有能引导读者入门的README，这是很掉价的。建议在源码包的根目录放一份README.md，内容包括：

• 项目简介：一句话说明系统是什么
• 技术栈：前端、后端、数据库分别用的什么
• 环境要求：微信开发者工具版本、Node.js版本、MySQL版本等
• 启动步骤：如何导入小程序、如何初始化数据库、如何启动后端服务
• 管理员账号：初始化的管理员账号密码（注意不要在生产环境使用）
• 项目结构说明：简单描述每个目录的作用
• 测试数据说明：如何造出便于演示的数据

这份README既是给你自己保存的工程记忆，也是答辩时导师拿到代码后快速上手的关键。我见过太多代码包，解压之后别人根本跑不起来，连安装步骤都没有——这种情况下即使功能做的再好，印象分也会大打折扣。

写在最后的几句实在话

这套订餐系统项目，我前前后后在不同阶段做过三个版本：最早用云开发快速实现，后来用Spring Boot + MySQL重写过，再到后来帮人做毕设指导，对"技术栈该怎么选、功能边界要划到哪、论文怎么写才饱满"这些问题的认知也在不断刷新。如果你问我现在要做一个毕设级别的订餐管理系统，最推荐的组合是什么，我的答案很明确：原生微信小程序 + Spring Boot + MySQL，前台和管理后台分开，核心业务围绕"购物车、下单事务、库存防超卖、订单状态机"这四个点做深做透，比堆十个华而不实的模块要管用得多。

项目跑通之后，你可以继续加一些有意思的东西：比如用ECharts做一个营业额趋势图，或者把菜品图片迁移到云存储做CDN加速，再或者给订单模块加上简单的消息模板通知能力。但所有扩展都要建立在基础闭环稳定的前提下。先把一整套流程跑通、写明白，再去谈优化和扩展，是我在这个项目上最大的体会。