企业官网建设流程全解析

毕业设计年年都在做，但校园美食商城这个題目我猜你没少搜过。SpringBoot + Vue + Java这个组合确实经典，但网上的教程要么只讲CRUD，要么上来就甩一堆你根本用不上的微服务概念。今天我不打算给你复读一遍官方文档，而是把一套真正能跑、能答辩、能写进论文的系统拆开揉碎，从需求到部署，从表结构到权限控制，把那些教程里不会明说、但你一定会踩的坑都讲清楚。

这篇内容适合谁？正在做毕业设计的本科生是主要读者，其次是想把校园外卖/食堂点餐做成实训项目的专科生或自学者。你不需要有生产级开发经验，但至少要会用IDEA、Maven、Navicat这些基础工具，并且对Spring Boot和Vue有最基础的了解。如果你连前后端分离是什么都还模糊，建议先补一下基础再回来看这篇，不然有些地方你会跟不上。

1. 这个系统到底要解决什么问题：从食堂排队到宿舍送达的三个核心痛点

先说需求。校园美食商城听起来只是个点餐系统，但如果你跟指导老师聊过就会发现，它真正要解决的是三个非常具体的问题。把这三个问题想清楚，你的需求分析章节基本就写完了，而且是有血有肉的分析，不是从百度文库抄来的那种空话。

第一个痛点是高峰期食堂排队效率低。中午十二点下课，几千人同时涌向食堂，窗口前全是人，排队十分钟起步，等坐下来吃饭已经十二点半了。这不是学生懒，是客观存在的效率问题。系统要提供的解决方案是"预点餐+到店自取"：学生可以在前两节课课间用手机把饭点好，选好取餐时间段，下课直接去窗口取餐，报取餐码或者让食堂阿姨扫码核销就行。这个场景的特点是：食堂不需要增加配送人力，学生减少了排队时间，食堂能提前备餐、提高翻台率。对毕设来说，它比纯配送逻辑简单得多，因为你不需要处理骑手调度这种复杂问题。

第二个痛点是校园内配送的"最后一公里"是盲区。校内宿舍区、教学区、图书馆之间距离不近，天气不好或者赶作业的时候真不想出门。校外外卖平台进不了校门，只能送到校门口围栏，学生还得走一段路去拿。所以校园外卖这个场景天然适合由校内人员来做配送——可以是勤工俭学的学生，也可以是食堂自己的员工。系统需要提供"校内配送"订单类型，配送范围限定在校内几个固定点位（比如宿舍楼、教学楼、图书馆），配送员接单后按楼栋集中配送。这里有一个很多毕设会忽略的点：配送费用的计算逻辑。按距离算太复杂，按订单金额阶梯算最简单实用，比如满15元免配送费，不满收2元。我后面会在订单模块详细讲这个规则怎么落地。

第三个痛点是好吃的档口/商家没有曝光渠道。每个学校一定有那种藏在角落但味道很赞的窗口，也一定有那种排队很长但其实一般的网红窗口。学生之间靠口口相传效率太低，系统需要一个"美食分享"板块，让用户可以对吃过的菜品打分、写评价、晒图，其他人就能根据真实的评价去选择。这个功能做好了，你的系统就不只是一个交易工具，而是带社区属性的平台，在答辩的时候可以非常自然地引出"用户粘性""UGC内容""社区激励"这些加分词。

所以你看，整个系统的功能拆解应该是这样的：用户端（小程序或H5页面）负责浏览、点餐、支付、评价、分享；商家端（网页后台）负责菜品管理、订单处理、库存管理、营业数据；管理后台处理用户审核、商家审核、平台运营数据。技术栈就用SpringBoot + Vue + MySQL + Redis这套组合，具体为什么这么选，下面细说。

2. 技术选型不是越新越好：SpringBoot 2.7 + Vue 2 + MySQL 8.0的搭配逻辑

技术选型是毕业设计里老师必问的问题，也是最容易翻车的地方。很多同学喜欢写"采用当前最新的Spring Boot 3.0和Vue 3.0"，看起来很潮，但实际动手就会发现处处是坑。我直接给你一套我自己验证过、能少走很多弯路的组合。

后端用Spring Boot 2.7.x，不要用3.x。为什么？Spring Boot 3.0是基于Jakarta EE 9的，很多教程和依赖还是javax.*前缀，你要用3.x就得把教程里所有的import javax改成import jakarta，而且很多第三方starter还没有跟进适配。你做一个毕设项目，时间有限，最重要的是能跑通、能复现，而不是追新。Spring Boot 2.7依然在社区维护期内，资料最全，遇到任何问题都能搜到解决方案。Java版本用JDK 8或者JDK 11都行，但别用JDK 17配合Spring Boot 2.7以下版本，会有兼容警告。我的建议是Spring Boot 2.7.18 + JDK 8，这套组合已经经过大量项目验证，稳如老狗。

前端用Vue 2 + Element UI，不用Vue 3 + Element Plus。我知道2024年了还在说Vue 2有点复古，但道理和Spring Boot一样：Vue 2的教程资源、第三方组件、踩坑记录是整个Vue生态里最丰富的，Element UI用起来也比Element Plus更顺手。你如果已经熟练掌握了Vue 3，用它也行，但如果是边学边做的状态，Vue 2 + Element UI的学习曲线更平缓，遇到问题几乎都能搜到现成答案。这里插一句，如果有人建议你用Vite + Vue 3 + TypeScript + Pinia这套全家桶，除非你真的很熟，否则毕设阶段没必要给自己上强度。

数据库用MySQL 8.0，ORM用MyBatis-Plus。MyBatis-Plus比原版MyBatis省事太多，内置的CRUD方法可以直接用，避免写大量重复XML；分页插件也内置了，一个PaginationInnerInterceptor搞定分页查询。不用JPA，因为JPA的复杂关联查询对新手不友好，调起来一头雾水。权限认证用Sa-Token，不用Shiro也不用Spring Security。为什么？Spring Security虽然功能强但学习曲线陡，配置繁琐，你大概率会在过滤器链里折腾半死。Sa-Token是一个国产的轻量级认证框架，登录、权限、踢人下线都是几行代码的事，文档还是中文的，对毕设和课设来说简直是对症下药。如果你没听过这个框架，去官网花二十分钟就能上手，后面我会给出实际集成代码。

还有一个必备组件是Redis，用来存验证码、购物车临时数据、热点菜品缓存。Redis在毕设里属于"有它更好，没它也行"，但如果你在论文里写"基于Redis的高并发缓存设计"，答辩老师会眼睛一亮。不过别担心Redis用起来有多复杂，就是几个字符串读写操作，我后面会给参考代码。

再补充一个隐藏加分项：对象存储。菜品图片、评价晒图需要一个存储位置。阿里云OSS和七牛云都有免费额度，但涉及身份证实名和银行卡绑定，有些同学嫌麻烦。我的建议是直接用本地存储，就是你服务器上放一个upload文件夹，图片上传后通过一个虚拟路径映射访问。毕设阶段这是最稳妥的做法，不依赖外部服务、没有额外费用、部署也不会出问题。在系统设计章节里可以写"考虑到平台初期体量和成本，图片存储采用服务器本地存储方案，后期可扩展为OSS/CDN"，这就是很合理的工程取舍。

3. 数据库设计是重头戏：从users到delivery_addresses的12张表串起整个业务链路

数据库设计直接决定你后面写代码是顺畅还是痛苦。我见过太多人建表的时候偷懒，到了写查询逻辑才发现缺字段、缺关联，回头改表结构就是连环修改，搞到心态爆炸。我按真实业务来推一遍，你看完就知道每张表存在的理由了。

先理清角色。系统里有三种角色：用户（学生）、商家（食堂档口/商家）、管理员（平台运营方）。对应地，第一张表是users表和role字段，我建议用枚举值区分：0-用户，1-商家，2-管理员。不建五张表搞那么复杂的RBAC，因为你的系统还没到那个规模。但商家有额外的店铺信息，所以单独拆一张shop表，和users表用shop_id关联。shop表要存：店铺名称、分类（窗口/档口/独立店面）、公告、起送价、配送费、营业状态（0-休息、1-营业）、评分、月销量。

接下来是核心交易链路，需要五张表。第一张food表存菜品，字段有：所属店铺shop_id、菜品名称、图片、描述、原价、现价、分类（热菜/凉菜/饮料/主食）、月销量、库存、状态（0-下架、1-上架）。这里有个细节：为什么要分原价和现价？因为要做"折扣价"展示，这在UI上能显著提升转化率，在论文里可以写"基于价格锚定效应的商品展示策略"，这是能写出花来的点。第二张cart表存购物车，字段有：user_id、food_id、quantity、selected（是否勾选）、create_time，在MySQL里对user_id和food_id建联合唯一索引，防止同一用户同一菜品重复插入变成两条记录。第三张orders表是核心中的核心，字段有：订单编号、用户id、商家id、订单类型（自取/配送）、订单状态、配送地址id、配送费、菜品总价、实付金额、备注、创建时间、支付时间、接单时间、完成时间。第四张order_detail表，和orders表是一对多，每一行的字段是：订单id、菜品id、菜品名称（冗余）、下单时的单价、数量、小计。注意"菜品名称"和"单价"要冗余存储，不能只存food_id，因为商家后续可能改名或调价，你的历史订单要保存下单那一刻的快照。第五张表delivery_address表，存收货地址，字段有：user_id、收货人、电话、楼栋、详细地址、是否默认。这里"是否默认"在业务里常见但是一个经典坑：默认地址不能有多个。正规做法是用逻辑判断，在Java代码里把所有地址设为0，再把当前这条设为1，而不是去数据库加唯一约束。

社区分享需要两张表：comment表存评价，字段有订单id、用户id、商家id、菜品id、评分（1-5）、内容、图片、点赞数、是否匿名、创建时间。这里要注意，匿名功能看起来简单，但会让"用户表关联查询昵称"变复杂，如果你时间紧张可以先砍掉，这是伪需求，不是核心卖点。然后一张reply表做评论回复，字段是：评论id、回复人id、回复内容、回复时间。为了减轻数据库压力，餐厅公告和轮播图可以合到一张banner表里，表名字段：图片地址、跳转链接、排序、生效状态。

你没看错，还需要一张delete_log表。就一个字段记录谁在什么时间删了什么，这在答辩时是绝佳的防守点。老师问"你这个系统怎么防止商家刷单/删差评？"你就能说"删除是软删除，所有关键删除操作都记录日志，管理员可追溯"。这一个表能给你挡掉一大半追问。

建表是第一步，但数据库设计真正拉开差距的是查询性能。这就要提到索引。users表的phone字段加唯一索引，这个不用多说。orders表在user_id、shop_id、create_time三个字段上分别加索引，order_detail表在order_id上加索引，comment表在food_id上加索引。凡是用于where条件、order by排序、join关联的字段都建索引，但别建太多，索引也是要占存储空间的，而且是写操作变慢的罪魁祸首。对于3000人以内的高校系统规模，做到这个程度已经完全够用，不要过早考虑分库分表，那是给千万级并发做的，写在毕业设计里是扣分项，因为"技术选型与系统规模不匹配"。

还有一点，所有表的主键统一用雪花ID，不要用自增ID。原因很简单：订单编号、评论ID这些数据如果你以后想导出到其他系统做对接，雪花ID天生带业务含义不容易撞，更重要的是如果以后分表，雪花ID可以直接拼接。MyBatis-Plus内置了雪花算法，你只要在主键上加@TableId(type = IdType.ASSIGN_ID)就完事了。

4. 后端开发的两条主线：鉴权流程和订单状态机是系统的心脏

后端代码你不可能一上来就全写，得有一条主线。我的建议是先从登录和鉴权入手，把地基打牢，然后集中火力打订单状态机——这两个是最复杂、最能体现你技术深度的模块。

登录怎么设计？用户输入手机号+密码，或者手机号+短信验证码。验证码需要对接第三方短信平台，阿里云短信和腾讯云短信都有免费额度，用起来不复杂：后端调用短信API发送验证码，并把验证码存到Redis里，设置5分钟过期，用户在页面填写后后端对比，一致才允许登录。如果你不想接短信平台，项目演示的时候就展示一个"固定验证码123456 + 模拟短信通道"，然后写清楚正式环境怎么替换成真实API，这也是合理的。

登录成功后，Sa-Token会生成一个Token返回给前端并存到Redis里，用户在访问需要权限的接口时，后端通过Sa-Token的注解校验登录状态。权限控制怎么做？我建议加一个拦截器，通过注解去标接口需要的角色，用Sa-Token内置的权限校验方式实现。比如管理员的接口加@SaCheckRole("admin")，商家接口加@SaCheckRole("merchant")，用户接口加@SaCheckLogin就行。这样代码非常干净，而且是一个在答辩时能让老师点头的设计。

订单状态机是整个系统最容易写成一坨浆糊的地方，所以我建议你画一张状态流转图再动代码。订单的初始状态是"待支付"，用户支付成功后变"待接单"，商家接受后变"待出餐"，出餐完成变"待取餐/待配送"，配送场景下配送员送达后变"已完成"，自取场景下用户取餐后变"已完成"。任何时候用户都可以申请"取消订单"，但要注意两种取消的区别：待支付状态直接取消；已经支付的状态下取消需要走退款流程，退款成功后订单流到"已退款"。这是订单模块最容易出bug的点——不区分已支付和未支付就允许取消，导致钱货两清出现了漏洞。

这个状态机怎么在代码里实现？我的建议是状态流转不要散落在Service的各个角落，而是集中管理。最简单的方式是写一个OrderStatusEnum枚举类，定义每个状态对应的整型值，然后在订单Service里写一个changeOrderStatus方法，接收订单Id、当前状态、目标状态，先查询数据库确认当前状态与传入状态一致，再更新为目标状态，并记录一条状态变更日志。核心代码如下：

public boolean changeOrderStatus(Long orderId, Integer expectedStatus, Integer targetStatus) { Order order = orderMapper.selectById(orderId); if (order == null) { throw new ServiceException("订单不存在"); } if (!order.getStatus().equals(expectedStatus)) { throw new ServiceException("订单状态已变化，无法执行当前操作"); } order.setStatus(targetStatus); // 记录订单状态变更日志 orderLogMapper.insert(new OrderLog(orderId, expectedStatus, targetStatus, System.currentTimeMillis())); return orderMapper.updateById(order) > 0; }

这段代码看起来简单，但它保证了一个关键特性：状态流转是"受控的"，不会被乱跳。待支付订单不可能直接跳到已完成，中间状态必须一步步走。这个"状态校验"逻辑就是业务规则在代码里的表达。很多自学的人写毕设订单模块，就是直接update status = 5，完全不校验当前状态，结果就是用户刷新一下页面、接口多调了几次，订单状态就乱了。

订单模块还有一个容易忽略但影响体验的点：库存扣减。用户下单时，系统会扣减菜品库存。如果你不做库存扣减，商家后台的库存管理就没有意义。这里有个并发坑是超卖问题——两个用户同时下单，都读到库存是1，然后同时卖出。解决方法很简单，SQL语句里加条件：UPDATE food SET stock = stock - 1 WHERE id = ? AND stock > 0。这个时候update语句在数据库层面是排他的，两个并发请求只有一个能改成成功，另一个affectedRows是0，你就可以提示用户"库存不足"了。这种基于"乐观锁/条件更新"的解法，比用Java代码加synchronized或者Redis分布式锁要简单得多，更符合毕设的定位。

关于支付模块，我单独说一下，因为它是被问得最多的地方。学生自己开发是不可能直接对接支付宝微信支付的，就支付宝当面付都要营业执照，微信支付更严。所以毕设里的支付功能有两种合法的实现方式。一种是免密支付的模拟，前端点"去支付"后弹出一个二维码（你可以用等额的收款码代替），用户"扫码"支付后，前端调一个接口通知后端支付成功，后端直接改订单状态为已支付。另一种是用支付宝沙箱环境，支付宝开放平台给开发者提供了一套沙箱环境，里面有一整套模拟支付网关，你要用这个就能实现全流程，但申请流程稍微复杂。我的建议是先用模拟支付把逻辑跑通，时间富余再换沙箱环境来加固。论文里就写"结合支付宝沙箱环境完成支付流程的模拟验证"，这样既真实又有边界。

5. 前端页面的开发顺序和核心交互：从登录注册到下单结算的页面落地

前端部分看起来内容很多，但如果你把高德地图、实时聊天这些"看起来高级但做起来要命"的功能都砍掉以后，真正要做好的核心交互其实只有三个：点餐流程、购物车结算、商家接单。

Vue项目怎么搭？用vue-cli创建项目，引入Element UI、Axios、Vue Router和Vuex（状态管理）。注意Vue 2和Element UI的版本要稳，用命令vue create项目名之后，在main.js里注册Element UI就行。Axios的统一封装建议做一下：拦截器里统一注入Token，响应拦截器里统一处理状态码，比如401跳转登录。这个小函数能让你的请求代码从一言难尽变得非常清爽，而且这也是答辩时可以说出口的亮点。

点餐页面是移动端用户第一次感受到好用不好用的地方。这里有一个业界成熟的交互方式是"左右两栏布局"：左侧显示菜品分类，右侧显示该分类下的菜品列表。用户点击左侧分类，右侧页面平滑滚动到对应区块；滚动右侧列表时，左侧分类高亮跟随变化。这种交互在美团、饿了么里都有，用户已经养成了习惯。设计上要简单的，用Element UI的Menu和Scrollbar就能实现。菜品卡片上要有图片、名称、月销量、价格、加号按钮。加号按钮点一下，前端就调后端接口，把菜品加入购物车。这里有个体验细节：点击加号时，按钮旁边显示当前已选数量，可以加减。数据是存后端Redis的，由于用户可能随时切换设备，存后端才能保证设备一致性。

购物车结算的交互是整个移动端的重头戏，你需要做好三个联动：底部购物车栏、购物车悬浮面板、结算页。底部购物车栏显示已选菜品总数量和总金额；点开后弹出购物车面板，能对每个菜品做数量增减、清空；结算页是确认订单页，展示商品清单、选择自取还是配送、选择配送地址、输入备注，最后提交订单。这里要注意提交订单前必须做二次确认，一个弹窗展示"共几件商品、应付多少钱"，让用户确认，可以显著降低误下单率。

商家端的核心交互是接单流程。商家登录后进入管理界面，有一个"今日订单"列表，订单分"待接单/待出餐/待配送/已完成"四个状态，用Tab页签切换。商家点"接单"，订单状态从待接单变成待出餐，订单卡片的背景色变成明亮的黄色。出餐完成后点"出餐完毕"，订单自动进入下一步骤。每一个按钮点击后，前端都会调后端接口推进状态，同时前端要对整个WebSocket做实时更新，否则商家还得手动刷新页面才能看到新订单。WebSocket在这里值得投入，代码量不大但用户体验是质的飞跃。用Spring的TextWebSocketHandler写一个WebSocket配置类，当前端建立连接时把商家ID注册到一个全局的会话管理Map里，后端订单状态变化时通过session.sendMessage推送给对应商家页面。

管理后台页面就相对基础和固定，用表格展示用户列表、商家列表、订单列表、数据统计面板。每一块的逻辑就是"查表+展示"，但要注意做搜索和分页，分页用MyBatis-Plus分页插件，搜索加个关键词、状态、时间范围的查询条件。统计数据可以用一个简单的折线图/柱状图展示每天的订单量、营业额，前端用ECharts画图，后端只需提供聚合查询接口（按天分组统计订单金额）。这块内容做到"清晰可用"的程度就够了，不需要特别炫酷。

6. 前后端联调与部署上线：Nginx反向代理、跨域问题和Linux服务器的坑

联调阶段是最容易让人绝望的时候，大多数问题集中在这四个地方，提前把对应的坑摸清能给你省下几天的调试时间。

第一个坑是端口配置导致的前后端分离跨域问题。前端的开发服务器是8080，后端是8081，前端fetch(axios)发的请求会触发浏览器的CORS跨域限制。解决办法有两个。开发环境就在后端写个CorsConfig类，配置允许跨域，方便调试；生产环境则不要用后端做跨域处理，直接用Nginx把/api路径反向代理到后端服务。用Nginx做代理还有个额外好处：前端的所有请求变成了同一个域，就不存在跨域的问题了，而且静态资源统一由Nginx分发，性能更好。这里插一句，不要偷懒在controller上加@CrossOrigin注解，那样会把跨域放开的逻辑散落在各个接口里，既不统一也不好维护，正确的姿势就是在网关层统一处理。

第二个坑是后端的静态资源映射。你本地上传的图片存在本地磁盘路径，但如果没做虚拟路径映射，前端就访问不到。Spring Boot在application.yml里配置一个自定义的静态资源映射，把upload目录映射成/upload/**路径。在Linux服务器上部署的时候，路径要用绝对路径，而且注意服务器目录权限，别把图片传上去却没有读权限。

第三个坑是前端路由的history模式。Vue Router默认是hash模式，地址栏会带一个#号。有人为了好看改成history模式，刷新页面就会404，因为服务器把路由路径当成实际文件路径去处理了，找不到对应文件就返回404。解决办法是让Nginx的try_files指令去兜底：所有找不到的路径都重写到index.html。这是每个上线的Vue项目都要做的配置，我这里把配置贴出来你直接用：

server { listen 80; server_name your_domain_or_ip; location / { root /usr/share/nginx/html/web; index index.html; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://localhost:8081/api/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } location /upload/ { alias /usr/local/foodmall/upload/; } location /ws/ { proxy_pass http://localhost:8081; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; } }

第四个坑是WebSocket的反向代理。WebSocket和HTTP不一样，它要协议升级，Nginx默认的proxy配置会把Upgrade连接头弄丢，导致前端连不上WebSocket。解决办法就是用我上面配置里写的，显式设置Upgrade和Connection头。localhost:8081是后端WebSocket服务真正监听的地址，/ws是整个项目WebSocket端点的统一前缀。

后端Spring Boot项目怎么打包部署？打包之前先在application.yml里确保数据库连接、Redis连接都指向服务器地址，然后把环境变量占位符用对，再用Maven的package命令打成jar包。不要用mvn spring-boot:run在生产环境跑，那可是前台进程，SSH一断就挂了。用nohup java -jar xxx.jar > app.log 2>&1 &命令，把程序放到后台运行，日志重定向到文件。日志文件的保留期建议采用按天切割的方式，用Logback配置实现，别让日志文件无限增长。

数据库迁移这里要格外小心。本地用MySQL 8.0，云服务器上也装MySQL 8.0，版本必须一致。因为MySQL 8.0改变了密码加密插件，5.x和8.x之间配合有问题。服务器的数据库导出导入直接用Navicat的转储SQL文件功能就行，但要注意字符集一致，转储的时候统一选utf8mb4。还有时区问题，服务器MySQL的时区可能不是中国标准时间。你可以在JDBC连接串里加serverTimezone=Asia/Shanghai，然后在JVM层面也会取服务器系统时间，两者要一致，否则订单创建时间会差8个小时。这个问题是我见过最隐蔽的坑，排查方向根本不在代码里，而在服务器时区配置上。

7. 论文和答辩的加分细节：把功能点包装成"业务亮点的技术支撑"

最后聊一个很多人忽视的事：做的是同一个系统，有人答辩90分，有人答辩70分。差距往往不在代码本身，而在于你怎么讲这个故事。这里我分享几个可以直接用的"包装思路"。

第一，把"支付流程"包装成"基于沙箱环境的支付安全验证"。不要只说"我接了一个支付接口"，而是说"考虑到毕设环境的合规要求，我基于支付宝沙箱环境搭建了模拟支付网关，通过RSA密钥验签保证支付参数不被篡改，同时结合订单状态机确保支付回调和订单状态的一致性"。这句话的信息量足够让老师知道你理解支付的安全本质。

第二，把"图片上传"包装成"图片审核与访问控制方案"。你可以在上传接口里加一层检查，限制图片格式和大小，然后再结合Spring Boot的拦截器对图片访问做权限控制。这个功能代码量很少，但能引出"资源访问安全"这个话题，在答辩时是很好的转折。

第三，把"简单的分页查询"包装成"基于MySQL索引优化的列表查询性能调优"。我这里说一个真实案例：订单表没加索引时，按时间范围查询会全表扫描。你用explain命令看到type=ALL，加上索引变成type=range之后，查询速度从200ms降到20ms。这是一个非常翔实的性能优化案例，贴一下explain的结果对比图，比什么架构图都好使。

第四，把"Redis"包装成"基于Redis的高并发热点数据缓存方案"。这个不用过度包装，你实际上用Redis存了用户Token、短信验证码和图片验证码，这些都属于"热点数据"。你在论文里写清楚哪些数据放Redis、为什么放Redis、Redis过期策略怎么设置，这就是一个完整且自洽的技术决策。

第五，也是很多毕设里最容易被忽略的，是"系统测试"章节要有干货，不要只写普通的功能测试。建议专门做一轮"订单状态机流转测试"，用表格形式记录每个状态下执行每个动作的预期结果和实际结果。这一张测试表能把你的订单模块的严谨性展示得淋漓尽致。然后再做一轮"并发下单测试"，用Jmeter或者Postman模拟50个并发用户抢购库存为10的菜品，看有没有超卖，说明你确实验证过并发问题。这个测试数据和结果放在论文里，可信度直接上一个台阶。

我在实际做这类项目的时候还有一个体会：不要在项目快结束时才想到写论文，而应该边做边写。每完成一个模块就立刻把对应的设计思路、遇到的问题记录下来，最后写论文只是整理而不是从零开始。这样的论文通常有真实的技术细节，不空洞，答辩的时候也更有底气。

最后想说的是，技术选型、代码实现、部署流程、论文包装，每一环都力图做到"能解释清楚为什么这么做"，就比绝大多数网上下个模板改改交差的作品要强很多。希望你不仅能跑通这套系统，更能在答辩时把每个设计选择背后的道理讲明白，那才是你真正从中学到的东西。