网上点餐系统毕业设计全攻略：从数据库设计到前后端分离实战

作为一个常年混迹各类项目、也帮不少人救过火的开发者，我看到“网上点餐系统”这类题目还是挺有感触的。它几乎是毕业设计里最典型的“麻雀虽小五脏俱全”：涉及用户端、商家端、订单流程、支付模拟，还得把前后端分离、权限控制、数据库设计这些点都串起来。如果你正打算做这个题目，或者已经被它折磨了一阵子，这篇文章应该能帮你把整个技术路线彻底理顺。我会从选题拆解、技术选型、数据库设计、后端实现、前端实现、联调部署一直到答辩避坑，按我实际做项目时的顺序完整讲一遍。

先说结论：这个题目非常适合作为前后端分离的练手项目，因为它既不会像纯后台管理系统那样单调，又不会像电商平台那样复杂到失控。一个点餐系统的核心闭环是“浏览菜品—加入购物车—下单—接单—结算”，围绕这个闭环把一对多、多对多关系理清楚，你的毕业设计就已经赢了一大半。下面直接进入干活模式。

1. 选题定位与核心需求拆解

1.1 这个题目到底在考什么

很多同学误以为毕业设计就是要做得“高大上”，于是加一堆用不上的功能。实际上，评审老师关注的永远是三件事：数据模型合不合理、业务流程通不通、技术点有没有真正掌握。网上点餐系统恰好能把这三件事一次性覆盖。

“网上点餐”的业务核心是订单。订单离不开菜品、用户、门店这几个基本实体。订单本身又要拆成主表和明细表，因为一个订单包含多个菜品，每个菜品又有下单时的快照价格。你把这几张表建清楚，CURD怎么扩展都只是体力活。反过来，如果一上来就堆功能、堆页面，最后数据库字段乱成一团，联调时就会出现“购物车数量同步不了”“订单状态改不动”这种抓瞎问题。

我建议你把题目拆成两个层面来理解：一是面向消费者的前台（微信风格的长列表、菜品分类、购物车角标、下单流程），二是面向管理员/商家的后台（菜品上下架、订单处理、销量统计）。这两个层面共用一套后端接口，但权限不同，这正好是前后端分离和权限控制的绝佳应用场景。

1.2 前后端分离到底是不是必须的

放在几年前，用 Thymeleaf 写服务端渲染也能交差，但放在现在，如果你为了省事放弃前后端分离，答辩时基本会被问倒。原因不是“现在流行”，而是业务场景确实需要分离：用户端和管理端是两套完全不同的界面节奏，用户端要轻快、交互多，管理端要表格密集、操作批量。

前后端分离的开发模式会让你把“接口设计”当成一件正经事来对待。比如下订单接口是 POST /api/order，更新菜品库存是 PUT /api/dish/status，我不需要在后端方法里返回一堆 HTML 片段，只需要定义清晰的 JSON 结构。前端拿到数据后自己渲染，调样式、改组件都不影响后端逻辑。

从部署角度讲，分离还意味着后端可以被多个前端复用。将来你想加一个小程序端，只要复用同一套接口，前端重新开发就行。这本身也是毕业设计里一个值得写进“项目展望”的亮点。

1.3 目标用户与功能清单

做任何项目之前，先定义清楚谁在用。我推荐把用户分成三类：普通用户、商家管理员、超级管理员（可选）。普通用户能注册登录、浏览菜品、加购物车、下单、查看订单状态；商家管理员能维护菜品分类和菜品信息、处理订单（接单、完成）；超级管理员可以管理用户和基础数据。

你不需要做支付网关对接，那样会把复杂度和安全要求提得太高。做个模拟支付即可：下单后订单状态变为“待支付”，前端弹出一个模拟收银台，点击“确认支付”就把状态置为“已支付，待商家接单”。这里只需要一个事务操作，既讲得清楚，又符合安全边界。

核心功能清单如下：

• 用户注册登录：用户名密码、JWT 令牌。
• 菜品分类与菜品展示：分类树、分页、关键字搜索。
• 购物车：单选加购、数量增减、角标联动。
• 订单流程：购物车生成订单、订单状态流转、订单明细。
• 商家后台：菜品管理、分类管理、订单处理。
• 数据统计：订单数量趋势、销量排行。

这些功能全部做完不会超过两周，却能覆盖一个完整信息系统的所有核心面。后续如果你想加积分、优惠券、配送地址，都是在订单主表上延伸字段和关联表，不会伤筋动骨。

2. 技术选型与开发环境搭建

2.1 后端技术栈版本怎么选

后端我建议用 Spring Boot 2.7.x 而不是 3.x。原因很现实：2.7 的生态最成熟，网上资料最多，遇到的依赖兼容问题最少。嗯，毕业设计的重点是跑通逻辑，不是当新版本小白鼠。Spring Boot 3 必须用 Java 17，而很多学校机器上的 JDK 还是 8，一旦版本对不上，环境问题就能耗掉你一周。

持久层我推荐 MyBatis-Plus。它比原生 MyBatis 少写大量 XML，单表 CRUD 直接用 BaseMapper 就能搞定，多表查询用 LambdaQueryWrapper 也够。另一个选择是 Spring Data JPA，但对于新手，JPA 的懒加载和级联操作很容易把人绕晕，不如 MyBatis-Plus 来得直观。

数据库用 MySQL 8.0，默认字符集设置为 utf8mb4，这样才能存 emoji 以及生僻字。如果你不想在本地安装 MySQL，用 Docker 拉一个 mysql:8.0 镜像也很方便，但要注意挂载数据目录，别把数据存在容器里，否则容器一删全没了。

2.2 前端技术栈的取舍

前端基础框架我用 Vue 3 + Vite。很多教程还在讲 Vue 2 + Vue CLI，但新项目没必要给自己埋坑。Vue 3 的组合式 API 写业务代码更顺手，Vite 的开发服务器冷启动快得多，整体体验比 Webpack 时代舒服好几个档次。

你还需要这三样东西：路由用 Vue Router 4，状态管理用 Pinia，UI 组件库用 Element Plus。如果目标是做一个更像真实点餐 App 的界面，可以再用 UnoCSS 或 Tailwind 自定义样式，但核心业务部分用 Element Plus 快速搭框架是最可靠的。移动端适配问题我后面会单独讲，这里先记住：Element Plus 的栅格布局能省你很多事。

构建工具上，Vite 默认配置已经足够。开发环境下用 proxy 把 /api 请求转发到 localhost:8080，避免前后端端口不一致带来的跨域问题。生产环境则用 Nginx 反向代理，把 /api 路径转发到后端服务，同时把前端静态文件托管在 /usr/share/nginx/html，这一套方案在毕业设计答辩现场非常常见，也最容易讲清楚。

2.3 开发环境逐步配置清单

我提供一个可以直接照抄的初始化步骤，省去你到处翻坑的时间。

1. 安装 JDK 8 或 11，配置 JAVA_HOME 环境变量。
2. 安装 Maven 3.8+，修改 settings.xml 里的镜像源。你懂的，国外源经常抽风，用阿里云的镜像仓能让你不至于卡在下载依赖这一步。
3. 安装 MySQL 8.0，创建数据库点餐系统库，比如 takeout_db，字符集选 utf8mb4。
4. 安装 Node.js 16 或 18，npm 源可以设置为国内镜像，否则 npm install 可能慢到怀疑人生。
5. 使用 Spring Initializr 生成后端骨架，依赖选 Spring Web、MySQL Driver、Lombok，后面手动加入 MyBatis-Plus 和 JJWT。
6. 使用 Vite 创建前端骨架：npm create vite@latest takeout-web，模板选 vue。
7. 安装前端依赖：vue-router、pinia、axios、element-plus。

这里有几个特别容易踩的细节。第一，Maven 镜像和 npm 镜像别弄混，云效、阿里云，认准一个就行。第二，MySQL 8 的驱动名是 com.mysql.cj.jdbc.Driver，不是旧版的 com.mysql.jdbc.Driver，URL 里别忘了加 serverTimezone=Asia/Shanghai，不然时间全偏。第三，Lombok 和你 IDE 的版本要匹配，新版 IDEA 一般没事，但老版本社区版如果没装 Lombok 插件，编译能过但运行报找不到方法，很玄学。

3. 数据库设计与权限模型详解

3.1 核心表结构设计

网上点餐系统的核心表我建议六张：用户表、菜品分类表、菜品表、购物车表、订单表、订单明细表。再加一张可选的轮播图表或地址表，但核心永远是那六张，设计原则是避免字段冗余。

用户表字段：id, username, password, nickname, phone, avatar, role, status, create_time。密码存放的是 BCrypt 哈希值，不是明文。role 用字符串存 USER 和 ADMIN 就好，不需要建用户角色关联表，因为系统只有两种角色，加一张表反而显得过度设计。status 是状态开关，可以用来做账号禁用。

菜品分类表字段：id, name, sort。sort 用于排序，比如饮品放前面还是后面。菜品表字段：id, category_id, name, description, image_url, price, stock, status, create_time。注意 price 我用 decimal(10,2)，不要用 double，涉及金额的类型必须精确。

购物车表字段：id, user_id, dish_id, quantity, selected。selected 字段表示是否勾选，前端购物车里的复选框就是对应这个字段。如果只支持整单提交，这个字段可以去掉；但如果你想让用户勾选部分菜品结算，就必须有这个字段。

订单表字段：id, order_no, user_id, total_amount, status, remark, create_time, pay_time。重点是这个 status，需要定义一组状态码：0 待支付、1 待接单（已支付）、2 已接单/制作中、3 已完成、4 已取消。订单明细表字段：id, order_id, dish_id, dish_name, dish_image, price, quantity，其中 dish_name 和 price 是从下单时刻的商品数据快照而来，防止商家后来改价导致历史订单金额变掉。

3.2 为什么我不用数据库外键

这是很多数据库课程里的“标准答案”和真实开发之间的差异点。课程里讲外键约束，但真实项目里我几乎不用物理外键。外键会带来什么问题？第一，删除菜品时如果被订单明细引用，会被约束挡住，你得先处理关联数据，很麻烦；第二，高并发插入订单时，外键校验会带来不必要的锁竞争；第三，一旦需要做分库分表，物理外键完全不可用。

我推荐用逻辑外键：在订单明细表里保存 dish_id，通过应用层保证数据的引用完整性。比如删除菜品前先查一下订单明细表有没有引用，如果有就做假删除，把菜品的 status 置为下架而不是 DELETE。这样既保留了数据可追溯性，又不会因为约束把业务卡死。答辩时可以主动向老师解释“为什么不用外键”，这往往是一个加分项，因为说明你思考过真实场景。

3.3 登录态与权限控制设计

登录态我用 JWT，而不是 Session。原因很简单：前后端分离之后，后端不能依赖 Cookie 里的 Session ID 来识别用户，因为跨域情况下 Cookie 要么被浏览器拦截，要么需要复杂的跨域配置。JWT 本身是无状态的，后端签发 Token 给前端，前端后续请求时在 HTTP 头里带上 Authorization: Bearer 。

JWT 里我存三个信息：userId、username、role。不存密码，不存敏感信息，因为 JWT 只是 Base64Url 编码，并不是加密，任何人都能解码看到 payload。签名由后端密钥掌控，防的是篡改，不是防窥视。

后端拿到 Token 后解析出 role，用拦截器做两级校验。第一级校验 Token 是否有效，第二级校验接口需要的角色。对于管理端接口，我会在 Controller 方法上写一个自定义注解 @RequireAdmin，拦截器发现当前角色的不是 ADMIN 就返回 403。这样权限逻辑集中在一处，而不是散落在每个业务方法里，代码可维护性高很多。

4. 后端核心模块实现（Spring Boot 实操）

4.1 统一响应体与全局异常处理

后端接口如果每个方法各返各的格式，前端解析起来就是灾难。我定义一个统一的 Result ：

@Data public class Result<T> { private Integer code; private String message; private T data; public static <T> Result<T> success(T data) { Result<T> r = new Result<>(); r.setCode(200); r.setMessage("success"); r.setData(data); return r; } public static <T> Result<T> error(String message) { Result<T> r = new Result<>(); r.setCode(500); r.setMessage(message); return r; } }

这个类看起来简单，但它决定了整个前后端协作的基础。前端 axios 拦截器看到 code 为 200 就直接用 data，否则弹 message。别小看这个机制，它能让你在联调时迅速区分“后端报错”和“前端逻辑问题”。

全局异常处理用 @RestControllerAdvice。我把业务异常和系统异常分开处理，业务异常返回 code 比如 400，系统异常记录到日志文件里，返回给前端的 message 则是“系统繁忙，请稍后重试”。日志打印用 Lombok 的 @Slf4j，关键请求参数也要打日志，否则出问题你连复现都无从下手。

4.2 JWT 登录与拦截器写法

登录接口的流程：根据用户名查用户，比对 BCrypt 密码，比对成功生成 JWT，返回给前端。生成方式和校验方式我都单独封装成 JwtUtil 工具类，不要在 Controller 里写 JWT 构建逻辑。

@Component public class JwtUtil { @Value("${jwt.secret}") private String secret; @Value("${jwt.expire}") private Long expire; public String generateToken(Long userId, String username, String role) { return Jwts.builder() .setSubject(String.valueOf(userId)) .claim("username", username) .claim("role", role) .setExpiration(new Date(System.currentTimeMillis() + expire)) .signWith(SignatureAlgorithm.HS256, secret.getBytes(StandardCharsets.UTF_8)) .compact(); } public Claims parseToken(String token) { return Jwts.parser() .setSigningKey(secret.getBytes(StandardCharsets.UTF_8)) .parseClaimsJws(token) .getBody(); } }

这里有一个重要坑点。JWT 的 signWith 方法在高版本 jjwt 库里的签名要求传入 Key 对象，而不是字符串。如果你用 0.9.x 版本，那按字符串传没问题；如果你用 0.11.x，必须用 Keys.hmacShaKeyFor(secret.getBytes())。这个版本差异导致了大量“能生成不能解析”的古怪报错，我在本地就踩过一次，查了好久才发现是 API 变更。

拦截器继承 HandlerInterceptorAdapter 重写 preHandle：

public class LoginInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { if (!(handler instanceof HandlerMethod)) { return true; } String token = request.getHeader("Authorization"); if (StringUtils.hasText(token) && token.startsWith("Bearer ")) { token = token.substring(7); try { Claims claims = jwtUtil.parseToken(token); request.setAttribute("userId", Long.valueOf(claims.getSubject())); request.setAttribute("userRole", claims.get("role")); return true; } catch (Exception e) { // 解析失败说明 token 过期或伪造 } } response.setStatus(401); response.setContentType("application/json;charset=UTF-8"); response.getWriter().write(JSON.toJSONString(Result.error("未登录或登录过期"))); return false; } }

注册拦截器时要注意静态资源放行。后端一般没有静态资源，但如果接入了文件上传图片预览，要把 /upload/** 这类路径放行，否则图片都加载不出来。

4.3 点餐下单的核心事务逻辑

下单是系统里最核心的方法，也是评委会专门盯着问的地方。绝不能写一个 INSERT 订单、再循环插入明细就完事，必须考虑完整的事务一致性。我推荐把下单和模拟支付拆成两个方法，下单时生成成功即冻结库存，支付时才扣减。

下单的核心逻辑：

1. 校验购物车选中项，取出菜品 ID 和数量。
2. 用 FOR UPDATE 锁住商品行，或者乐观锁控制库存。毕业设计用乐观锁就可以：UPDATE dish SET stock = stock - #{quantity} WHERE id = #{dishId} AND stock >= #{quantity}，返回受影响行数来判断是否超卖。
3. 生成订单主表，状态为 0 待支付。
4. 批量插入订单明细。
5. 清空对应购物车项。

整个方法上用 @Transactional(rollbackFor = Exception.class)，确保任何一个环节抛异常，前面插入的订单和扣减的库存全部回滚。注意 rollbackFor 必须写成 rollbackFor = Exception.class，只写 @Transactional 时默认只回滚 RuntimeException，普通异常抛出来不会回滚，这是新手最容易犯的错误。

模拟支付接口更简单：把订单状态从 0 改成 1，同时记录支付时间。这里同样要校验订单归属，防止用户把别人的订单支付了。接口里必须带上 userId，下单接口保存订单表时要记录 user_id，支付时先查订单的 user_id 是否等于当前登录用户。

4.4 统计报表的 SQL 优化思路

后台管理端要展示销量排行和订单数趋势。很多同学直接用 groupBy 把全表查出来，数据量少时还好，量一大数据库立刻卡顿。其实这类报表查询的核心不是写复杂 SQL，而是要让索引命中。

订单表按 create_time 建索引，统计某天订单数时，SQL 写成：

SELECT DATE_FORMAT(create_time, '%Y-%m-%d') AS day, COUNT(*) AS cnt FROM orders WHERE create_time >= '2024-01-01' AND create_time < '2024-02-01' GROUP BY DATE_FORMAT(create_time, '%Y-%m-%d');

如果不加时间范围限制，MySQL 会扫描全表。你可以在开发时用 EXPLAIN 看一眼，理论上应该走 range 而不是 ALL，这一点要能主动在答辩时说清楚。销量排行则会 join 菜品表，按菜品分组求和，数据量大时同样要先限定时间范围。

统计查询一般不加载到内存超过几百行，因为维度只有天和菜品，不会膨胀。如果你想做得更漂亮，可以引入定时任务每天凌晨统计一次，把结果写入统计表，查询时直接查结果表。这种方式叫做“空间换时间”，在功能演示时性能提升非常明显，也是答辩里很好讲的优化点。

5. 前端核心模块实现（Vue 实操）

5.1 Axios 封装与请求拦截

前端如果每个页面里直接写 axios.get，将来改接口前缀或者加 Token 就非常痛苦。我习惯在 src/utils/request.js 里封装一个 axios 实例：

import axios from 'axios' import { ElMessage } from 'element-plus' import router from '@/router' const request = axios.create({ baseURL: '/api', timeout: 10000 }) request.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers.Authorization = `Bearer ${token}` } return config }) request.interceptors.response.use( response => { const res = response.data if (res.code !== 200) { ElMessage.error(res.message) return Promise.reject(new Error(res.message)) } return res.data }, error => { if (error.response && error.response.status === 401) { localStorage.removeItem('token') router.push('/login') } ElMessage.error('网络请求失败') return Promise.reject(error) } ) export default request

注意我返回的是 res.data 而不是 res，这样调用方不需要每次解一层包装，业务代码清爽很多。401 时自动跳登录页，也算把之前后端拦截器设计了一次闭环。

5.2 购物车与订单确认的交互设计

前端“加购”这个动作看上去简单，但实际上要处理好三个地方：购物车图标角标、商品卡片按钮状态、购物车页面的数量修改。我推荐用 Pinia 管理购物车列表和总数量，组件之间不做 event bus 传递，避免数据不同步。

购物车 state 里维护一个 items 数组，每个元素包含 dishId、name、price、quantity、selected。加购操作去重有两种选择：后端把购物车表当持久化数据，或者前端纯本地存储。我建议采用后端持久化，因为这样才能做到“换个设备购物车还在”，这也让购物车表的设计有了真实意义。前端加购时调用后端接口，返回最新数量后更新 Pinia。

购物车页面的加减按钮，不能每点一下都等后端响应再做本地更新，那样体验会很卡。正确做法是乐观更新：点击加号立刻更新本地数量和总价，同时向后台发请求。如果请求失败，再回滚本地状态并提示错误。这种交互细节写进“项目心得体会”里，老师会觉得你真懂前端。

下单确认页要展示商品列表、总金额和用户备注。备注字段要限制长度，防止恶意用户塞超长字符串。提交订单时把 quantity 和 dishId 做成数组传给后端，后端用订单明细表接收。前端收到订单号后跳转到“订单列表/订单详情页”，而不是停留在购物车页，这样用户的认知路径是完整的。

5.3 路由守卫与不同角色的首页区分

前端路由需要区分用户端和管理端。用户端的页面包括首页、菜品列表、购物车、我的订单；管理端的页面包括后台布局、菜品管理、分类管理、订单管理、数据统计。两者不能互相串访。

我配置路由时给管理端加一个 meta.requiresAdmin。全局前置守卫里同时判断登录态和角色：

router.beforeEach((to, from, next) => { const token = localStorage.getItem('token') if (to.meta.requiresAuth && !token) { next('/login') return } const role = localStorage.getItem('role') if (to.meta.requiresAdmin && role !== 'ADMIN') { next('/') return } next() })

这里有一个小细节：用户登录后把基本信息存到 localStorage，但不要存密码等敏感信息。只存 userId、username、role、token。页面刷新时 Pinia 里的用户信息会清空，这时候需要从 localStorage 恢复。我封装了一个 init 方法在 App.vue 的 created 里调用，保证刷新页面不丢登录状态。

管理端的侧边菜单我也根据角色动态生成，不是写死。游客看不到管理入口，管理员进系统后默认落在数据统计页。这个“动态菜单”功能用 Vue Router 的 addRoute 实现比较高级，但如果你时间紧张，暂时固定菜单再配合路由守卫拦截也能交差，功能上并无硬伤。

6. 联调部署与源码组织建议

6.1 前后端联调最容易崩的三个点

前后端各自跑得通，合在一起就挂，这事太常见了。我联调时遇到过三个高频问题，先列出来，你遇到的时候能少走弯路。

第一个是跨域配置。如果你用 Vite 的 proxy，前端页面代码里的请求路径必须以 /api 开头，后端 Context Path 不要重复配置成 /api。也就是说，前端请求 /api/auth/login，后端 Controller 的 RequestMapping 是 /auth/login。如果后端又配了 context-path=/api，那么实际接口路径会变成 /api/auth/login，而前端又加了一层 /api，最后变成 /api/api/auth/login，404 没跑。

第二个是时间格式串台。后端返回 LocalDateTime 时默认序列化格式是数组或带 T 的 ISO 字符串，前端显示出来很奇怪。统一在 application.yml 里配置：

spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+8

第三个是字段命名不一致。后端数据库字段用下划线 user_id，实体类用驼峰 userId，如果 MyBatis-Plus 没开启 map-underscore-to-camel-case 全局配置，查询结果里 user_id 就映射不到 userId，返回的 JSON 缺失字段，前端数据全是 undefined。这个配置通常默认开启，但最好主动确认一次。

6.2 生产环境构建与 Nginx 配置

演示的时候你大概率不会用生产模式，Vite dev server 跑起来就够了。但毕业设计说明书里大概率要写“部署方案”，而且答辩现场如果网络抽风，本地开发服务器挂了会很尴尬。所以我还是建议把生产构建流程跑通一遍。

前端执行 npm run build，生成 dist 目录。后端正用 Maven 打包：mvn clean package -DskipTests，生成 jar 包。本地测试可以直接 java -jar target/takeout-backend.jar，前提是 MySQL 已启动。

Nginx 配置模板我给出最小可用的版本：

server { listen 80; server_name localhost; root /opt/takeout-web/dist; index index.html; location / { try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }

这里最容易出错的是 proxy_pass 的结尾斜杠。location /api/ 配上 proxy_pass http://127.0.0.1:8080; 没有斜杠，等价于把 /api 前缀保留放在一起转发；如果有斜杠，路径会被替换为 /api 之后的部分。两种写法对应不同后端接口设计，我建议统一用没有斜杠的形式，然后后端接口路径不要带 /api 前缀，让 Nginx 统一处理前缀，结构最清晰。

6.3 源码目录结构与说明书章节对应

源码结构清晰与否，直接影响评阅老师对你的第一印象。后端我用标准的包结构：controller、service、mapper、entity、dto、config、common。前端按功能模块分目录：views/user、views/admin、api、utils、stores、router、components。

所有配置项都要放进配置文件变量，禁止在代码里写死。数据库密码尤其不能写在业务代码里，要写在 application.yml 里，然后通过 @Value 注入到数据源配置。就算项目是本地 demo，也要养成这种习惯，答辩时提起“配置与代码分离”，是一个能加印象分的点。

毕业设计说明书的大纲可以直接对照源码结构来写：第一章绪论对应项目背景和意义，第二章技术选型对应项目开发环境，第三章系统设计对应数据库表和接口设计，第四章系统实现对应前后端核心代码讲解，第五章测试对应功能测试和联调结果。你的源码里每个 service 类的方法名尽量对应说明书里的小节标题，这样写论文时不用来回映射。

7. 常见问题排查与答辩避坑实录

7.1 高频故障速查表

以上每一条我都实际踩过，不是从文档里顺手抄的。尤其是中间两条，事务不生效和 Token 解析失败，卡了我最长的时间。你如果开发到一半突然遇到这些魔幻问题，先按表里检查，别急着怀疑人生。

7.2 答辩时老师常抓的三个软肋

很多同学的代码能跑，但被老师一问就漏气。我见过的高频追问有三个。

第一个是“购物车为什么不直接存 Redis”。老师想考察的是你对缓存的理解。你可以回答：Redis 适合临时性高并发场景，但这个项目为了降低架构复杂度、保证数据不丢失，把购物车持久化到 MySQL，后续如果要做大规模并发再引入 Redis 做缓存层。这样回答既表达了你了解 Redis，又说明你的方案是有针对性的，不是不会。

第二个是“订单并发超卖怎么办”。这个问得最多。你可以把扣库存的 SQL 写法展示出来：UPDATE dish SET stock = stock - #{quantity} WHERE id = #{id} AND stock >= #{quantity}，并解释为什么这条语句天然保证不会扣成负数。如果他想听锁机制，你再继续说悲观锁和乐观锁的区别，以及在这个量级里乐观锁足够。

第三个是“JWT 和 Session 有什么区别”。标准答法是：Session 存储在服务端，需要共享存储才能支撑多实例部署；JWT 自包含，服务端无状态，直接靠签名验签，天然适合前后端分离和分布式环境。但要承认 JWT 的缺点是难以主动注销，所以通常配合短期过期和前端登出清 Token。这种“既讲优点也讲局限”的回答比单纯吹捧 JWT 可信得多。

7.3 我在实际动手中的几个独家体会

第一，别等项目做完再写文档。我建议每做一个模块就在说明文档里同步贴一张截图和一段核心代码，否则临到答辩前三天熬夜补文档，质量差到离谱。我的习惯是每天收工前花十五分钟记录“今天完成了什么、踩了什么坑”，答辩时直接把这些一手资料加工成“项目难点”章节，真实又具体。

第二，演示数据要提前准备好，而且要有逻辑。不要用“菜品1”“菜品2”这种傻瓜数据，菜品名称、价格、分类要按真实场景配好，比如“招牌红烧肉 28 元”“冰镇酸梅汤 6 元”。订单数据里要有不同状态和不同日期的多条记录，这样打开数据统计页时趋势图才有起伏，演示效果完全不一样。

第三，做一点“超出预期”的小功能，但不要多。比如菜品搜索的关键字高亮、订单列表的分页、图片上传后实时预览。选择一个跟你核心业务有结合的小亮点做精，比堆砌五个半成品功能有用得多。我当时做了一个“订单状态时间线”，用户在订单详情页能看到从下单到完成的每一步时间戳，老师当场就问了这个数据是怎么组织和展示的，成了整场答辩互动最多的一个点。

最后再分享一个小技巧。这个项目做完之后，不要急着删开发记录。把数据库初始化脚本、启动说明、常见问题说明写进项目的 README，并且把 README 挂在仓库首页。不仅是自己以后回看方便，而且如果指导老师或者评审想跑一下你的项目，照着 README 就能十分钟内启动成功，这会大大降低沟通成本，也侧面证明你的工程化意识。不要小看这一个小动作，很多同学的项目在老师手里根本跑不起来，就是差一份像样的启动说明。你可以按我的经验，在项目根目录建一个 docs 文件夹，把 SQL 脚本、环境变量示例、接口文档表格全放进去，答辩的时候直接把这份文档展示出来，效果不比你半小时的代码演示差。