SpringBoot+Vue餐厅点餐系统开发实战：从需求到答辩避坑指南

springbootvue餐厅点餐管理系统这类题目基本上是每年计算机类毕业设计和课程设计里出现频率最高的几个方向之一。我前前后后也指导过不少学生做类似的系统自己也完整开发过一版对这个题目的套路、难点、以及老师评审时到底看什么算是摸得比较透。如果你正准备做这个题目或者已经在做了这篇文章应该能帮你把整个项目的脉络捋清楚从需求拆解、技术选型、数据库设计到核心功能实现、联调排错再到文档整理和答辩演示全程我都结合自己的实操经验来讲。我不太喜欢讲那种教科书式的流程我更愿意直接告诉你哪些地方容易卡住哪些坑一定要避开以及为什么这个系统要这么设计。1. 项目到底在解决什么问题——需求拆解与方案选型很多同学拿到餐厅点餐管理系统这个题目第一反应是赶紧去敲代码。这其实是个误区。做任何系统第一步一定是把需求想清楚尤其是这种经常拿来当课程设计的题目——老师看重的不是你用了多新的技术而是你对业务逻辑的理解是否完整、系统设计是否合理。1.1 点餐系统的真实业务场景餐厅点餐绝不是用户选菜下单这么简单。你在设计系统之前先把自己代入到一家真实的小型餐厅里从顾客进店到离开整个流程大概是这样的顾客落座服务员递上菜单或者引导顾客扫码/在平板上查看菜品顾客浏览菜品分类凉菜、热菜、主食、饮品等查看价格和图片可能有口味备注需求顾客选好后下单后厨收到订单开始做菜服务员或系统通知出餐顾客用餐完毕结账现金、扫码、会员余额等老板或店长需要看到今天的营收、热门菜品、订单记录这个流程拆出来系统的核心角色就清晰了顾客端点餐、商家端管理。很多人的系统里还有配送员角色说实话纯餐厅堂食场景用不着除非你把题目扩展成餐厅外卖点餐系统否则多设计一个角色只会增加工作量答辩时还容易被追问。所以我的建议是先明确这个系统是堂食点餐还是堂食外卖。如果题目就是餐厅点餐管理系统就按堂食来做把点餐、下单、支付或下单后结账、后台管理这几条主链路做扎实比盲目加功能更稳妥。1.2 为什么是SpringBootVue这个组合的价值在哪里SpringBoot Vue是目前全栈项目最主流、也最稳妥的组合。不是因为它最新而是因为它最适合快速交付 结构清晰 好解释这三点。SpringBoot负责后端接口。它的好处是开箱即用、约定大于配置你不需要去手动配一大堆XML。内置Tomcat打成jar包就能跑。对于课程设计来说SpringBoot的生态足够丰富安全认证可以用Spring Security或JWT持久层可以用MyBatis或MyBatis-Plus功能往哪个方向扩展都有现成方案。Vue负责前端页面。采用前后端分离架构Vue通过Axios调用后端接口数据驱动视图更新。Vue的组件化开发模式特别适合这种多页面、多状态的管理系统比如菜品列表、购物车、订单状态这些功能拆成组件后代码干净也方便维护。为什么不是用JSP如果你还在用JSP做这种系统我只能说除非学校硬性要求否则不要选。前后端分离是现在实际开发的主流做法答辩时用前后端分离架构作为亮点去讲比用传统服务端渲染更容易加分。更重要的是Vue的生态里有Element UI这种现成的组件库后台管理页面做出来非常规整视觉效果好老师印象分会高不少。选型的另一个考虑点是可控性。自己做项目最怕的就是用了自己完全不懂的技术出了问题没法排查。SpringBoot Vue任何一个环节出问题你能找到的海量资料都是最多的。你可以不懂底层原理但你至少要知道去哪里查、怎么改。这一点在实际开发中非常重要。1.3 角色划分与功能模块设计我见过很多学生的系统角色只有一个管理员然后管理员什么都能干页面堆在一个后台里。这不是不可以但业务边界模糊答辩时容易被问那顾客端呢顾客怎么下单所以角色的划分要清晰。按照餐厅堂食场景我建议划分三个角色每个角色的功能边界如下角色核心功能范围顾客注册登录、浏览菜品、加入购物车、提交订单、查看我的订单、在线支付或到店结算商家/管理员菜品分类管理、菜品信息维护、订单管理确认/出餐/完成、订单统计、营收数据查看系统超级管理员商家账号管理、基础数据初始化可选课程设计可以弱化顾客端的典型路径是登录 → 查看菜品 → 加入购物车 → 提交订单 → 查看订单状态。商家端是登录 → 管理菜品 → 查看新订单 → 确认出餐 → 查看统计报表。这里要注意不要为了功能多把支付功能做得太重。对接真实的微信/支付宝支付需要商户号、证书、回调地址等个人开发根本申请不下来。最合理的做法是模拟支付下单后点击模拟支付直接更新订单状态为已支付。答辩时主动说明真实支付需要企业资质这里做了模拟接口预留了扩展位这个说法老师是认可的。2. 系统架构与数据库设计——先把地基打好很多初学者一上来就写代码写到一半发现表的字段不够用或者关联关系混乱只能推翻重来。数据库设计是这类系统的命脉先把地基打好后面写代码才顺。2.1 前后端分离架构如何落地前后端分离字面意思是前端和后端是独立的两个工程部署时也是两个独立服务通过HTTP接口通信。具体的落地方式后端工程SpringBoot端口默认8080提供RESTful API返回JSON数据前端工程Vue CLI或Vite创建的项目开发时端口8081通过Axios请求http://localhost:8080/api/xxx生产环境部署时把后端接口地址配置到vue.config.js的proxy里开发环境下最大的坎是跨域。浏览器默认不允许从一个端口访问另一个端口的接口。解决办法有三条路后端加CrossOrigin注解最省事但只适合单个Controller后端配置全局CORS适合开发阶段前端配置代理生产环境推荐我的习惯是前端配置代理在vue.config.js里加module.exports { devServer: { proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } }这样前端请求/api/xxx就自动转发到后端8080端口避免了跨域问题而且这个代码在部署时也适用属于标准做法。后端接口路径我习惯统一前缀/api比如/api/user/login、/api/dish/list。前后端约定好接口文档格式比如统一返回{ code: 200, message: 成功, data: ... }。这样后端不管返回什么前端都可以统一处理错误踩坑少很多。服务层Service、数据访问层Mapper、控制层Controller三层结构不要省。虽然业务简单时三层看起来繁琐但是老师看的是你的工程化思维三层分离、职责明确答辩时能讲的东西就多了。2.2 数据表设计的关键细节点餐系统的核心表不需要设计很多但每张表都要经得起推敲。我直接给出一份经过实际检验的表结构设计字段已经过精简没有多余的用户表 t_user字段名类型说明idbigint主键自增usernamevarchar(50)登录名唯一passwordvarchar(100)加密存储roletinyint0-顾客 1-管理员nicknamevarchar(50)昵称avatarvarchar(255)头像URLphonevarchar(20)手机号create_timedatetime创建时间菜品分类表 t_category字段名类型说明idbigint主键namevarchar(50)分类名称如热菜sortint排序号数值越小越靠前菜品表 t_dish字段名类型说明idbigint主键category_idbigint所属分类namevarchar(100)菜品名称pricedecimal(10,2)价格注意用decimal不要用doubleimagevarchar(255)图片URLdescriptionvarchar(500)菜品描述statustinyint1-上架 0-下架salesint销量用于热门菜品排序订单表 t_orders字段名类型说明idbigint主键order_novarchar(32)订单编号唯一如202501011530001234user_idbigint下单用户total_amountdecimal(10,2)订单总金额statustinyint0-待付款 1-已支付 2-已接单 3-已完成 4-已取消remarkvarchar(255)用户备注create_timedatetime下单时间订单明细表 t_order_detail字段名类型说明idbigint主键order_idbigint关联订单dish_idbigint菜品IDdish_namevarchar(100)菜品名称冗余存储防止菜品信息修改后历史订单变动pricedecimal(10,2)下单时单价quantityint数量subtotaldecimal(10,2)小计这里有两个细节值得敲黑板第一个价格字段用decimal不要用double。double有精度丢失问题0.10.2不等于0.3这在金融场景里是大忌。虽然课程设计可能不会触发这个bug但你用了decimal答辩时主动说价格涉及金额为保证精度选择decimal这是一个明显的加分项。第二个订单明细表冗余了dish_name。为什么因为菜品信息是可能被修改的——价格变了、名字改了。如果订单明细不记录快照后面统计历史订单时菜名可能对不上。这个设计叫业务冗余是实际开发里的常用做法。同理下单后把菜品的sales字段1是为了统计热门菜品总不能在报表查询时现场count那样性能会非常差。2.3 接口设计的约定与规范接口是整个系统的骨架规范了前后端的配合方式想清楚再动手事半功倍。我常用的统一返回结构是下面这样public class ResultT { private Integer code; // 200成功500失败401未登录 private String message; private T data; public static T ResultT success(T data) { ResultT result new Result(); result.code 200; result.message 操作成功; result.data data; return result; } public static T ResultT error(String message) { ResultT result new Result(); result.code 500; result.message message; return result; } }核心接口清单如下这是一个最小但完整的集合POST /api/user/login登录参数为username和password返回token和用户信息POST /api/user/register注册GET /api/category/list菜品分类列表GET /api/dish/list菜品列表支持按分类筛选、按名称模糊搜索GET /api/dish/detail?idxx菜品详情POST /api/order/create提交订单参数包含订单明细列表和备注GET /api/order/myOrders当前用户的订单列表GET /api/order/detail?idxx订单详情含明细PUT /api/order/pay?idxx模拟支付PUT /api/order/status更新订单状态管理员操作GET /api/admin/order/list管理员查看所有订单支持时间、状态筛选GET /api/admin/stats营收统计、订单量趋势、热门菜品Top10接口的命名不要学某些项目乱起/queryOrderInfo这种驼峰路径虽然能跑但不规范。业界标准是RESTful风格顺序就是资源名词动作语义清楚。答辩时说我的接口遵循RESTful设计规范又是一句加分话术。3. 核心功能实现——从登录到下单全链路这个部分我按照用户从进系统到完成下单的顺序来拆解把每个环节的实现要点和容易出错的地方都说到位。3.1 用户登录与权限控制登录功能几乎所有系统都有但点餐系统要处理的细节比想象中多。比如用户登录后在后续请求中如何识别身份最简单的是每次请求都带上username但这样既不安全也不专业。标准做法是用Token登录成功后后端生成一个Token用JWT或者UUID都行返回给前端前端把Token存到本地每次请求时在请求头里带上Authorization字段后端通过拦截器校验Token校验通过就放行否则返回401。我建议直接用JWTJson Web Token因为JWT本身就是一串包含用户信息的加密字符串后端不需要把Token存在session里直接解析就能得到用户信息。引入依赖dependency groupIdio.jsonwebtoken/groupId artifactIdjjwt/artifactId version0.9.1/version /dependency生成Token的核心代码大致是这样的public String generateToken(Integer userId, String role) { return Jwts.builder() .setSubject(String.valueOf(userId)) .claim(role, role) .setIssuedAt(new Date()) .setExpiration(new Date(System.currentTimeMillis() 1000L * 60 * 60 * 24)) // 24小时有效 .signWith(SignatureAlgorithm.HS256, your-secret-key) .compact(); }前端在Axios请求拦截器里统一加Tokenaxios.interceptors.request.use(config { const token localStorage.getItem(token); if (token) { config.headers.Authorization Bearer ${token}; } return config; });权限控制的核心诉求是顾客不能访问管理员的接口。后端可以通过拦截器检查JWT里带的role字段来实现。不想写得太复杂的话也可以用Spring Security但对课程设计来说手写拦截器就够了——代码量小而且你完全知道它在干什么答辩不会被问倒。3.2 菜品管理与分类展示菜品管理是商家端的核心。后台要支持菜品的增删改查以及上下架操作。要注意这里的删除最好是假删除也就是只改status字段而不是真的把记录删掉。原因有两个历史订单明细关联着菜品数据真删了会出问题上架下架的切换本质上就是一个状态位没必要删数据。我建议在后端删菜品时只做一个状态更新PutMapping(/admin/dish/status) public ResultVoid updateStatus(RequestParam Long id, RequestParam Integer status) { dishService.updateStatus(id, status); return Result.success(null); }前端菜品管理页用Element UI的表格组件支持搜索、分页、编辑弹窗。分页查询建议后端用MyBatis-Plus的Page插件几行代码就搞定。关键接口是GetMapping(/dish/list) public ResultPageDish list(RequestParam(defaultValue 1) Integer pageNum, RequestParam(defaultValue 10) Integer pageSize, RequestParam(required false) Long categoryId, RequestParam(required false) String name) { return Result.success(dishService.pageQuery(pageNum, pageSize, categoryId, name)); }菜品图片的处理也是一个小重点。课程设计阶段不要傻傻地做文件上传需要处理存储路径、访问映射、文件大小限制等一系列问题耗时且收益低。最简单的做法是图片字段存外链URL菜品图片找一个免费的图床或就用网上的公开图片URL贴上去。把精力省下来放到核心业务逻辑上这是性价比最高的选择。3.3 购物车与下单流程实现购物车的实现方式有两种常见方案存后端服务端购物车和存前端LocalStorage。我推荐用前端方案或者确切地说是前端存储 后端兜底的混合方案。为什么因为购物车是用户在当前会话内的临时行为没必要每一次增删都请求后端那样增加接口开销也没有太大意义。用LocalStorage或者Vue的状态管理Pinia就能搞定核心是一个数组每个元素包含dishId、name、price、quantity。用户点击提交订单时前端把这个数组作为参数传给后端后端一次性生成订单。这样做的好处是后端接口简单、响应快而且答辩时你能讲清楚为什么购物车状态放在前端而不是后端这个设计决策——这是老师很喜欢问的问题。下单接口的后端逻辑是这个系统的核心事务性很强我贴一下关键代码Transactional public OrderVO createOrder(OrderCreateDTO dto, Integer userId) { // 1. 创建订单主表记录 Order order new Order(); String orderNo generateOrderNo(); // 生成唯一订单号 order.setOrderNo(orderNo); order.setUserId(userId); order.setStatus(0); order.setRemark(dto.getRemark()); // 2. 计算总金额并逐条保存订单明细 BigDecimal total BigDecimal.ZERO; for (OrderItemDTO item : dto.getItems()) { Dish dish dishMapper.selectById(item.getDishId()); if (dish null || dish.getStatus() ! 1) { throw new BusinessException(菜品不存在或已下架); } BigDecimal subtotal dish.getPrice().multiply(new BigDecimal(item.getQuantity())); total total.add(subtotal); OrderDetail detail new OrderDetail(); detail.setOrderId(order.getId()); detail.setDishId(dish.getId()); detail.setDishName(dish.getName()); detail.setPrice(dish.getPrice()); detail.setQuantity(item.getQuantity()); detail.setSubtotal(subtotal); orderDetailMapper.insert(detail); // 3. 累加销量 dish.setSales(dish.getSales() item.getQuantity()); dishMapper.updateById(dish); } order.setTotalAmount(total); orderMapper.insert(order); return OrderVO.fromEntity(order); }这里要注意为什么计算金额要在后端算而不是信任前端传来的total因为前端传过来的数据是可以被篡改的。如果前端把单价改成0.01后端又信任了那就是白送。所以后端必须根据数据库里真实的单价重新计算总金额。这个点是面试和答辩的高频问题也是安全意识的体现。还有Transactional注解别忘了加。下单操作涉及多张表的写入订单主表、明细表、菜品销量更新任何一步失败都应该整个回滚否则就会出现订单创建了但明细没存这种脏数据。在实际检查代码的时候这个注解是否出现是一个很重要的评判标准。订单号生成也有讲究。不要用自增ID当订单号因为会暴露平台的订单量而且不美观。我习惯用yyyyMMddHHmmss 随机数或者时间戳 用户ID后缀保证唯一即可。3.4 订单状态流转与后台管理订单状态是整个系统里最容易让初学者混乱的地方。我把状态设计成一条清晰的流转链待付款(0) → 已支付(1) → 已接单(2) → 已完成(3)待付款状态下用户可以取消订单进入已取消(4)这个流转链必须从前端下拉框和后端接口两个层面同时限制死。比如已完成的订单不能再跳回已支付否则数据就无法信赖。在后端实现时给订单的update操作增加前置状态判断PutMapping(/order/status) public ResultVoid updateStatus(RequestParam Long orderId, RequestParam Integer targetStatus) { orderService.transitStatus(orderId, targetStatus); return Result.success(null); }在Service层用switch-case控制合法的状态迁移非法迁移直接抛异常。这是非常经典的业务逻辑写法。后台订单管理页面需要支持分页查看所有订单按时间和状态筛选查看订单详情含明细商品列表执行接单和完成操作能直接看到订单关联的用户名和备注为了让管理员看到订单在订单查询时多表联查一下用户表取username返回一个VO视图对象而不是直接把实体类返回给前端。这也是一个体现工程习惯的细节Controller不应该直接暴露Entity而是返回VO/DTO。4. 联调、调试与部署——你有很大概率踩的这些坑前端后端分别开发联调阶段必然是问题集中爆发期。我把自己遇到过的、以及学生们咨询次数最多的问题整理成清单每个都是真实的实战经验。4.1 跨域、参数格式与JSON魔法跨域问题在开发时最常遇到。现象是浏览器控制台报Access to XMLHttpRequest at http://localhost:8080/... from origin http://localhost:8081 has been blocked by CORS policy。这个报错第一次看到会慌其实是标准问题解决方案就是我前面说的前端代理或者后端加跨域配置。参数格式对不上也是高频问题。举个例子前端Axios默认以JSON格式发送数据如果后端Controller用RequestParam接收就接不到参数报Required request parameter xx for method parameter type is not present。解决办法是统一规范POST请求用JSON后端用RequestBody接收GET请求用Query参数后端用RequestParam。不要混用。日期格式问题。前后端互传时间如果直接传Date对象格式化经常出问题。最简单的方案是后端返回时把时间格式化为字符串用JsonFormat(pattern yyyy-MM-dd HH:mm:ss)注解标注前端直接展示。排序就用字符串排序因为这种格式字符串的字典序就是时间序。4.2 典型的运行时异常与排查路径我整理了下面这5个最常见的运行时报错几乎做这个题目的人都会遇到异常信息出现原因排查思路NullPointerException调用了空对象的方法最常见是查询结果为空没判空定位报错行号看哪个对象是null加判空逻辑Duplicate entry xxx for key username数据表唯一约束被违反注册了重复用户名后端注册接口先查重或者捕获唯一键异常BadSqlGrammarExceptionSQL语句写错、表名或字段名拼写错误开启MyBatis日志看控制台打印的SQL复制到数据库客户端里执行Invalid bound statement (not found)Mapper接口和XML namespace对不上检查Mapper接口、XML的namespace和id是否正确Failed to convert property value of type java.lang.String to required type java.lang.Integer前端把字符串当数字传给后端Integer字段前端确保数字用number类型或后端增加转换排查问题的核心方法就一条看日志不要瞎猜。SpringBoot控制台默认就会打印完整的异常堆栈第一行就是异常类型往下翻几行就能看到你项目代码里的报错位置。很多同学遇到报错第一反应是是不是我环境没配好其实90%的情况就是代码级别的bug日志一看便知。4.3 前后端分离项目的上线部署思路虽然课程设计阶段很多老师不要求真部署但你能主动把项目打包部署起来在答辩时直接打开演示页面效果完全不同。整体的部署步骤是后端打包mvn clean package -DskipTests打包完成后在target目录下生成xxx.jar上传到服务器华为云、腾讯云、或者本地虚拟机都行执行java -jar xxx.jar --server.port8080前端打包npm run build生成dist静态目录。为了让前端页面去请求后端接口需要把跨域代理配置到生产环境。我通常用Nginx在nginx.conf加一段server { listen 80; server_name your-domain.com; root /var/www/dist; index index.html; location / { try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://localhost:8080; proxy_set_header Host $host; } }这样用户访问80端口就是前端页面访问/api/路径时Nginx把请求转发给后端的8080端口完美解决了生产环境的跨域问题。数据库连接的话把配置文件里的spring.datasource.url改成服务器上的MySQL地址即可。我的建议是哪怕你的服务器只是一台阿里云学生机也把这套流程完整走一遍。因为你写项目部署方式Docker/Nginx jar包 静态资源和只写在IDEA里能跑完全不是一个级别。5. 文档撰写、答疑边界与交付经验这个项目标题通常还包含了源码文档调试基础修改答疑这几个词在实际的交付场景里文档和答疑往往比代码本身更影响最终评价。5.1 技术文档要写清楚的三件事这类项目通常需要交付一篇毕业论文或者课程设计说明书核心要写清楚三件事第一件事你的业务模型是怎样的。画清楚用例图、角色权限图。不需要画得很复杂但用例图要覆盖你实现的所有功能点。写文档时每个功能模块先写业务背景再写功能描述再写核心流程这是标准的由浅入深结构。第二件事数据库设计要有理有据。每一张表都要列出字段名、类型、是否主键、含义说明。最好加上E-R图图片加分。重点讲清楚订单主表与订单明细表的1对N关系、外键逻辑、冗余字段的设计原因。光贴表结构不解释老师会觉得你只是抄了一套表。第三件事核心功能的代码实现要点。不用贴全部代码但核心代码必须有一段拿得出手的讲解。比如你下单逻辑的事务处理、JWT的鉴权流程、金额精度的控制。把代码贴出来然后分步骤解释为什么这么写。有分析、有思考的文档读起来才是设计与实现而不是代码粘贴。文档写作有个实用技巧先写目录再写内容。目录结构按照绪论 → 需求分析 → 概要设计 → 详细设计 → 系统实现 → 系统测试来组织这是最标准的学术结构。边写代码边记录自己做了什么、遇到什么问题、怎么解决的两周后你不会记得这些细节。5.2 演示Demo的准备工作答辩演示是整个项目的临门一脚。这里分享几个实战中总结出来的演示要领演示遵循顾客下单 → 管理员接单 → 数据统计这条主线控制在6-8分钟。先打开前端页面以普通账号登录浏览菜品加两个菜到购物车提交订单模拟支付。然后切换管理员账号登录看到新订单确认接单、出餐、完成。最后打开统计页展示今天卖了多少单、营业额多少、销量最高的菜是哪几个。演示时有一个几乎必踩的坑数据库里没有数据或者菜品图片是空的。演示效果大打折扣。我的建议是预置至少四五个菜品分类每个分类下七八道菜图片外链都填好再创建一个测试账号预置两三条已经完成的订单。这样你在演示统计报表时页面才不寒酸。另一个很实际的经验是演示前把后端先启动好不要当着老师的面才去敲命令。实在不行准备一个降级方案页面截图放在PPT里万一现场出bug还能讲下去。5.3 我在这类项目上踩过最大的坑最后聊聊交付和答疑的经验。给他人提供的服务里最容易出现的问题是需求不明确就去改代码。有一次别人要求加一个会员功能我想当然地理解为是会员等级和折扣结果对方想要的是充值送余额。一周时间白费了。现在我的做法是任何修改需求先确认三件事这个功能放在哪个角色下数据存在哪张表交互流程从哪一步开始搞清楚再去动代码。单是加一个按日期查询订单的功能就要分清楚是查询所有订单、还是查某个用户的订单、日期范围是闭区间还是开区间。沟通清楚了再动手效率反而更高。答疑的过程中我还发现找人答疑的同学经常卡在一些非常基础的环境问题上。数据库连不上、Maven依赖下载失败、端口被占用。所以给任何人的第一份交付文档里我建议都包含环境注意事项这一章JDK版本必须是哪个Maven要用阿里云镜像数据库字符集要设置成UTF-8启动顺序是先起后端再起前端。这些看起来简单其实是项目能不能顺利跑起来的分水岭提前写进文档能省去后面大量的重复答疑时间。6. 复盘这类全栈项目到底值不值得认真做回到题目本身SpringBootVue餐厅点餐管理系统网上源码一抓一大把。有人认为网上有现成的改改就能交但我觉得既然要花时间做这个项目还是值得把它当成一次真实的工程训练来对待的。这套系统麻雀虽小五脏俱全。前端有用户交互、状态管理、路由控制后端有RESTful接口设计、JWT权限控制、事务处理、异常管理数据库有主外键关联、逻辑删除、冗余字段设计。这些是任何大型系统都绕不开的基础能力。你把这一条线做通、做明白后面接触分布式、微服务、容器化很多思路都是相通的——无非是把单机版的模块拆到多个服务里但核心的软件设计思想一点没变。我也见过不少同学做的时候能跑就行代码里全是拼装、逻辑混乱、命名随意写完就扔。到了答辩被老师问你这个功能怎么实现的支支吾吾答不上来最后分数不理想。说到底课程设计考察的不只是代码能不能跑而是你有没有真正理解、能不能说清楚。只要你把为什么这么设计想透了不止答辩能过这些设计思维也是可以跟着你一起进职场的东西。就拿价格字段用decimal、订单明细冗余菜名、库存更新用事务、购物车状态放前端、订单状态机严格流转这几个点来说如果每一处你都能说出设计理由你已经比很多开发过一两年的人要靠谱。这才是我认为做这个项目真正值得的地方。