企业官网建设流程全解析

选择这套SpringBoot+Vue+MySQL的网上点餐系统作为毕业设计，算是选到了一个难度适中、技术栈主流、需求明确的好题目。前后端分离的模式能展示完整的工程化能力，点餐购物车、订单状态流转、后台菜品管理这些功能又天然适合用关系型数据库建模，写论文和答辩时故事线很顺畅。这篇内容我按自己带毕设时最常给学弟学妹讲的顺序来梳理，从项目怎么拆解、数据库怎么设计，到后端接口怎么写、前端怎么对接，再到部署和论文怎么润色，把能踩的坑和能加的亮点都列出来，希望能帮你把毕业设计做得既扎实又省力。

1. 项目全貌与核心领域拆解

1.1 这套系统到底解决什么问题

做毕业设计最忌讳的就是上来写代码，写到最后自己都说不清项目是干什么的、给谁用、解决什么痛点。这套网上点餐系统，说白了就是给食堂、小餐厅、校园快餐店这类场景做的线上点餐平台，替代纸质菜单和口头点单的流程。

它的核心用户有两类，一类是顾客，打开网页就能浏览菜品分类、加购物车、下订单、查订单状态，甚至还能看到菜品图片和价格，不用挤在窗口前排队；另一类是餐厅管理员，登录后台管理菜品上下架、调整价格、处理订单状态（比如接单、出餐、完成）。

所以整个平台天然拆成两个子系统，前台点餐门户和后台管理端。前台给顾客用，后台给商家用，两边共用同一套用户体系但权限不同。这正是毕业设计需要体现的“业务理解”和“需求分析”能力。围绕这个项目，你的开题报告和论文就围绕“中小型餐饮门店订单管理效率低、人工记录易出错、高峰期拥堵”来写，立意和现实意义就都有了。

1.2 技术栈选型为什么是这套组合

SpringBoot是当前Java后端最主流的快速开发框架，内嵌Tomcat，不用打War包部署，自动配置机制能少写大量XML配置，尤其适合一个人完成的毕设项目。Vue是前端渐进式框架，组件化开发思路清晰，配合Element UI这类组件库效果出得很快。MySQL是关系型数据库的经典选择，订单、用户、菜品、分类之间天然存在外键关联逻辑，MySQL的事务机制能保证下单过程中数据的完整性。

还有一个重要原因是这套技术栈的社区生态太成熟了。随便一搜就有海量文档、课程、问题解决方案，论文查重率可控，答辩时老师问到什么细节你都能从网上找到对应知识点，不会陷入孤立无援的境地。你要是选了个冷门框架，出了问题都没地方问。

常见的技术疑问我直接列个对比表说清楚：

选型逻辑核心就一条，毕业设计不是炫技，要的是在自己完全掌控的情况下，把完整的业务闭环跑通。

2. 数据库设计是毕设的重头戏

2.1 核心表结构与字段设计思路

网上点餐系统看起来功能不少，但拆开看核心表不超过八张。我按依赖关系给你理一遍，你建表的时候按这个顺序来：

用户表（sys_user）存登录账号和密码，角色字段区分管理员和普通用户。密码记得用MD5或者BCrypt加密存储，明文密码在答辩时会被老师点名批评。用户基本信息包括昵称、手机号、创建时间。

菜品分类表（category）字段最简单，分类名称、排序号、是否显示。这个表独立抽出来而不是直接写死在菜品表里，是为了前台点餐时的菜品分类导航，以及后台分类管理的增删改。

菜品表（dish）是前台的门面。字段包括菜品名称、分类ID、图片URL、原价、会员价或者折扣价、描述信息、月销量、是否上架状态。有一点容易被忽略，就是加一个sort排序字段，前台展示时按这个字段排列，否则你把新菜品加进去就会跑到最后面，体验很差。

购物车表（cart）往往被新手漏掉，这个表的作用是保存用户未下单前选好的菜品。字段包括用户ID、菜品ID、数量、加入时间，用户ID和菜品ID做个唯一索引防止同一个菜品加两次。设计时考虑用Redis做购物车，但我个人建议毕设就用MySQL表实现，逻辑直观，答辩容易讲清楚。

订单主表（orders）是整个系统最核心的信息载体。订单号要设计得对用户友好，可以是时间戳加随机数，存一个字符串。字段包括用户ID、订单号、总金额、订单状态（待支付、已支付、已接单、已出餐、已完成、已取消）、下单时间、支付时间、收货人信息（姓名、电话、地址）、备注。这个表建议给state加索引，后台查询待处理订单时走索引效率会明显提升。

订单明细表（order_detail）和订单主表是一对多关系。每一行记录一个菜品在订单里的快照信息：菜品名称、下单时单价、数量、小计金额。为什么要做快照？因为菜品表的价格和名称随时可能被管理员修改，订单历史记录必须保留下单那一刻的商品信息，不能跟着变。这个逻辑在论文的数据一致性章节能写出几百字。

管理员操作日志表（sys_log）可选但有加分效果，记录谁在什么时候改了哪个菜品价格、上下架了什么商品。这个表的设计直接响应了“系统安全性”和“可追溯性”需求，答辩时能拿出一个有思考深度的亮点。

2.2 表关系梳理与ER图规划

ER图是论文必放的图，你必须能把表之间的箭头关系讲清楚：

分类表和菜品表是一对多，一个分类下面有好几个菜。用户表和购物车表是一对多，一个用户购物车里有多条记录。购物车表里存了菜品ID做外键关联，这样你就能在展示购物车时通过关联查询把菜品图片、价格拉出来展示在页面上。用户表和订单表是一对多，一个用户能下多笔订单。订单表和订单明细表是一对多，一笔订单包含多个菜品记录。

为了保证数据完整性，数据库设计时有两个细节需要自己做好权衡。外键约束在建表语句中加不加？我的建议是不加物理外键，逻辑上通过实体类关联和Service层控制。因为物理外键在删数据时容易出现约束阻塞，联调阶段各种诡异问题都来源于此。你只要在涉及删除操作时手动检查有没有关联子记录就行。这个做法在论文里也要体现一句“为保证系统扩展性和删除效率，采用逻辑外键而不是物理外键”，显得你是真的懂设计，不是只会抄表结构。

建表语句字符集全部用utf8mb4，因为MySQL默认utf8存不了emoji和生僻字，很多交易备注里真有表情符号，不用utf8mb4会导致写入报错。排序规则选utf8mb4_general_ci就够了，性能好，毕设场景不需要复杂的国际化排序。

2.3 初始化数据的准备工作

数据库脚本除了建表，还要附带一份初始化数据脚本，包括默认管理员账号（比如admin）、几个菜品分类、十几个菜品带图片URL、一个测试用户账号。这份数据的作用有两个层面。第一是你自己开发调试时不用每次手动造数据，省很多事。第二是部署文档里写了执行SQL脚本，别人拿到你的源码按文档操作后系统是直接能看到的，不用空表自己填，体验完全不一样。

菜品图片处理也是一个常见的决策点。很多同学把图片转成Base64直接存数据库，字段又长又占空间，响应也慢。正确做法是把图片文件放在前端项目的静态资源目录下，或者单独上传到服务器某个目录，数据库只存图片的访问路径URL。部署后通过Nginx配置静态资源映射，前端就直接能加载图片。菜品的图片URL建议填相对路径，比如/dish/xxx.jpg，而不是http://localhost:8080/dish/xxx.jpg，不然换服务器就全裂了。

3. SpringBoot后端核心实现

3.1 项目初始化与分层架构搭建

创建一个SpringBoot项目的方式有很多，你直接用IDE的Spring Initializr就行。依赖选择上别贪多，核心就几个：Spring Web、MySQL Driver、MyBatis、Lombok。MyBatis和MyBatis-Plus之间我更推荐后者，因为单表查询基本不用写XML，BaseMapper直接提供增删改查，你只需专注业务逻辑，代码量能少一大半，数据库操作出错的概率也大幅下降。

项目结构按标准三层架构组织。Controller层只做参数接收和结果封装，不写业务代码。Service层承载业务逻辑，比如下单时要校验库存、算总价、生成订单号、清空购物车，这些动作在Service里编排。Mapper层对应数据库操作接口，MyBatis-Plus的QueryWrapper解决动态条件查询。实体类entity对应每张表，字段名和表字段驼峰映射。

统一返回结果类Result是最常见的架构设计，定义code、message、data三个字段。成功返回Result.success(data)，失败返回Result.error(“xxx”)。前端拿到后通过code判断请求是否成功再决定怎么渲染。这一步相当于给前后端通信定了一个协议标准，没有这个类，前端代码会写得很乱。

全局异常处理注@RestControllerAdvice，捕获业务异常和运行时异常转为统一格式返回。比如菜品库存不足抛一个自定义业务异常，前端就能弹友好提示，不会看到一行白底英文报错。这在论文的“系统健壮性”部分是一个标准表述点。

3.2 登录鉴权与JWT方案落地

毕设做登录功能，我建议直接上JWT而不是传统的Session。JWT是无状态认证方案，后端不用存Session，认证信息放在Token里由前端保存（一般是localStorage）。每次请求浏览器自动带上Token，后端通过拦截器解析Token判断用户身份。

实现逻辑分三步。用户提交用户名密码，后端校验通过后用用户ID和角色信息生成一个Token，有效期设24小时或者7天都行。前端把Token存下来，在Axios请求拦截器里加Authorization请求头。后端写一个拦截器Interceptor，排除掉登录、注册、菜品列表这些公开接口，对需要认证的接口统一从请求头取Token解析。解析失败就返回401状态码，前端收到后跳到登录页。

为什么要做这个设计而不直接用Session？因为前后端分离后前端可能部署在Nginx的80端口，后端跑在8080端口，跨域情况下Session的Cookie处理很麻烦且容易失效。JWT把状态从服务端转移到了客户端，天然适配跨域部署。这个选型逻辑在论文里要写，老师就爱问“为什么不用Session”，你要能说出无状态扩展性和前后端分离适配性这两条。

密码加密用BCryptPasswordEncoder，注册时加密存储，登录时matches对比。不要用MD5直接存，MD5撞库风险太大，老师看到会知道你没有安全意识。引入spring-security-crypto依赖就够，不需要整套Spring Security，免得配出一堆没用的过滤器链。

3.3 核心业务接口与下单事务控制

整个后端的业务精华集中在下单流程。前端点击“提交订单”后，后端下单接口做的事按顺序是有逻辑的：

接收订单参数，包括用户ID（从Token解析）、收货人信息、备注、购物车ID列表。加@Transactional注解开启事务，同时校验购物车里的菜品是不是上架状态。遍历购物车计算整单总金额，把每个商品的当前价格乘数量累加。生成唯一订单号，规则用当前时间戳加用户ID加随机三位数，够用且不会重复。保存订单主表和订单明细表，批量插入明细。删除用户购物车中已下单的记录。

为什么要加事务注解？因为以上任何一步失败，比如商品刚好下架了或库存不足，前面写入的订单主表和明细表必须全部回滚，否则就产生一笔不完整的脏订单。这也是答辩时老师最常问的知识点：事务的ACID特性怎么在项目里体现的。你说出“下单接口通过@Transactional保证原子性，失败自动回滚”这句，这个问题的分就拿到了。

菜品上下架接口同样有讲究。修改菜品时只改state字段而不是删除记录，已下架菜品用户的购物车和下单记录还保留数据，只是不能再购买。删除菜品更是要做保护性校验，如果该菜品已存在于订单明细中，提示“该菜品已有订单记录，建议改为下架”而不是直接删。这就是数据一致性的应用场景，论文测试部分能写进测试用例里。

4. Vue前端实现与页面交互

4.1 项目结构与路由配置

前端项目用Vue CLI或者Vite初始化，目录结构上按views、components、router、store、utils、api来组织。views目录放页面级组件，比如Home.vue是点餐主页面，Login.vue登录页，Cart.vue购物车页，Orders.vue我的订单页，Admin目录下放后台管理的菜品列表、订单管理、分类管理等页面。components放公共组件，api目录按模块封装Axios请求。

路由分两级维度考虑。第一是登录权限控制，未登录用户访问个人中心、购物车、订单页面时，通过路由守卫router.beforeEach检查本地有没有Token，没有就重定向到登录页。第二是角色权限控制，管理员才能访问后台管理页面，判断当前用户的角色字段，不是管理员就重定向回首页。这个守卫逻辑是Vue项目“安全保障”的核心代码，和前端体验直接相关。

路由模式的坑我提前说掉。后端部署时如果用过vue-router的history模式，Nginx不配置try_files，直接刷新某个子路由页面就是404。开发时用hash模式能规避这个问题，但URL会多个#号。生产部署我更建议history模式配好Nginx，写论文截图时URL好看，部署文档里把这个配置写清楚也是一个细节加分项。

4.2 状态管理与购物车交互

购物车数据存哪里是个经典问题。方案选择上有存后端数据库表和存前端Vuex或者localStorage两种。我建议用后端表存储，理由是数据更可靠，用户换浏览器或设备数据还在，下单时也要基于数据库里的购物车结算。前端页面每次加载购物车都调用接口获取最新数据，配合菜品状态实时判断哪些菜已下架。

Vuex在后端存储方案下承担的任务就轻了，主要管理用户登录态和购物车全局数据，避免组件之间反复传值。比如点餐页加购一个菜，需要跳转到购物车页还能看到刚才加入的商品，这个场景用Vuex存储全局购物车状态非常自然。

Axios封装时统一处理三件事：请求拦截器自动加Token，避免每个接口手动写；响应拦截器判断HTTP状态码和业务code，401时手动清空Token并跳登录页；统一错误提示，后端返回的错误信息用Message组件弹出。

有意思的是商品数量加减逻辑中数值的精度问题。前端加购的菜品数量要限制正整数，输入框不能直接让用户输负数或小数。后端Controller加@Min(1)注解做参数校验，两道防线都做上。单价计算也要注意前后端以哪边为准，永远以后端算出的总价为准，前端显示值只做参考，不然用户改一下前端数据就能以错误价格下单。

4.3 前后端联调与跨域处理

开发阶段前端跑在8081端口（Vue默认），后端跑在8080，端口不同就必然产生跨域问题。解决方式有两个常用方案，二选一即可。

第一种在后端代码里写一个CorsConfig配置类，设置允许的请求来源、方法、请求头，允许携带凭证。这种方式开发和生产都生效，最省心。第二种是前端Vite的proxy代理配置，前端所有/api开头的请求由Node服务代理转发到后端，浏览器看到的是同源请求，没有跨域。这种方式只在开发环境生效，打包后由Nginx统一处理。

我推荐方式一为主，方式二为辅。理由很简单，后端全局允许CORS是标准做法，一个类搞定，不会再出现某个接口能访问某个接口又跨域的诡异情况。前端代理因为挂在开发服务器上，一旦你直接用打包产物测试，代理就失效了，坑过很多人。

5. 部署流程与文档整理

5.1 前后端打包的完整流程

部署环节是毕业设计文档里必须写得清晰的部分，也是老师验收时可能会实际操作的环节。整个部署流程分三大块。

后端打包最省心，Maven执行package命令就行。关键点是配置文件中数据库连接信息用环境变量占位，或者改成部署服务器的实际值。内置Tomcat端口如果没有特殊要求就保持8080。打包产物是一个Jar包，用java -jar命令就能启动。如果你用了文件上传功能，注意指定静态资源上传路径和打包路径分离，不能把用户上传的图片存到Jar包内部目录，重启就没了。

前端打包执行npm run build，产物是一个dist静态目录。这个目录要交给Nginx托管或者放进Tomcat的webapps，但毕设场景Nginx是首选。打包前检查api请求地址是绝对路径还是相对路径，如果请求地址写成了http://localhost:8080这类硬编码，部署到服务器就成了链接到本机，必然失败。正确做法是用环境变量或相对路径/api，配合Nginx反向代理转发到后端服务。

Nginx配置示例，核心配置就几行：

server { listen 80; server_name localhost; location / { root /usr/share/nginx/html/dist; index index.html; 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; } }

/api前缀的请求转发到后端的8080端口，相当于把后端的Controller路径做了一层URL重写，前端不用暴露后端真实端口给用户。

5.2 部署文档的写作结构与细节

部署文档是整套源码交付物中不可缺少的一环，阅卷老师和你所在学校的毕设验收老师会严格按照文档来尝试运行系统。文档写得烂会导致扣分，写得好能提升整体评价。我认为一份合格的部署文档至少要包含以下章节：

环境要求章节，列百分百兼容的版本：JDK 1.8、Maven 3.6+、Node 14+、MySQL 5.7+、Nginx 1.18+。每个人的本地环境不会都一样，你还要按“已验证兼容版本”和“理论上兼容版本”分开列，例如MySQL 8.0理论上兼容5.7的脚本，但如果有sql_mode不同导致的报错要写一句“降级到5.7最稳”。

数据库初始化章节，给数据库脚本和导入方法，命令行方式要写mysql -u root -p < db.sql，图形化工具方式给Navicat操作截图标注。你自己搭建时的截图要全部保留，这是最好的插图素材。

后端启动章节，把application.yml配置文件中数据库账号密码改成自己的，然后执行mvn spring-boot:run或java -jar xxx.jar。初次启动后看日志有没有报错，访问健康检查地址确认服务正常。

前端启动章节，npm install安装依赖然后npm run serve开发模式启动，访问http://localhost:8080。注意npm install可能因为网络源问题卡住，文档里加上设置淘宝镜像的命令npm config set registry https://registry.npmmirror.com，这个细节能救回无数人和无数分。

5.3 如何验证系统是否部署成功

很多同学部署完不知道怎么算成功，闷头瞎试。我建议你写一个完整的验收清单，部署完成后按顺序过一遍才算完事。

第一项，打开首页能看到菜品分类和菜品列表，图片正常加载，不显示裂图。第二项，注册一个新用户账号，能正常登录跳转。第三项，随便加几个菜到购物车，数量加减正常，总价计算正确。第四项，提交订单后能在“我的订单”页面看到这笔订单，状态是待支付。第五项，用管理员账号登录后台，能在订单管理里看到这条新订单并修改状态。第六项，刷新一遍系统，数据不丢，用户还在登录态（Token还有效）。

验收清单完全可以照搬到论文的系统测试章节，不用另写一套测试内容。这就是会写文档的人把时间花在复用上，而不是重复造轮子。

6. 论文写作与答辩准备思路

6.1 毕业论文的章节结构建议

毕业设计与论文是配套交付物，论文不是代码的复述，而是整个项目的工程化说明。一篇合格的系统设计论文，大致结构按照下面这个逻辑展开。

摘要部分概括系统背景、开发技术、实现功能和测试结论，300字左右。关键词列三到四个：网上点餐系统、SpringBoot、Vue、MySQL。

绪论章节按三段走法：研究背景说明餐饮行业数字化趋势和传统点餐痛点，国内外研究现状简述现有产品和论文技术平台，研究意义和创新点总结。创新点是关键，哪怕你只是把购物车体验做成了餐厅模式也要包装出来，比如“本系统为中小餐饮门店提供轻量化、低成本的数字化点餐解决方案”。

系统需求分析是论文中最好写的部分，两节内容搞定。功能性需求列表按用户模块、菜品模块、购物车模块、订单模块、后台管理模块分别列条数。非功能性需求，围绕系统性能（页面响应不超过2秒）、安全性（密码加密和权限控制）、可维护性（三层架构）来写即可。

系统设计章节是论文核心，包含总体架构图、功能模块划分、数据库ER图、核心表结构字段说明、前后端交互时序图。这一章能写40页以上，你需要画图而不仅仅是写代码。画图工具有很多，关键是要统一风格，手画草图扫描上去很减分，用统一颜色和字体的绘图工具。

系统实现章节按模块为主线，每段开头先放页面截图，配上关键代码片段加上实现思路说明。代码不要贴太多，每段贴核心方法就好，把业务逻辑和信息流转讲清楚，让老师看到你理解这个模块在做什么而不只是会用代码。

系统测试章节是给系统挑刺的部分，反而显得你专业。功能测试列表把核心功能用例、输入条件、预期结果、实际结果全部列成表格。性能测试写压测结果，比如用工具模拟50个并发用户下单接口的平均响应时间在200ms以内，这种数据能体现专业度。

总结与展望章节简短，总结当前系统完成的功能和收获，指出不足和后续的改进方向，比如引入缓存、推荐算法、小程序端等。

各章节内容分布我已经给你列好了页数分配建议：绪论15%左右、需求分析15%左右、系统设计30%左右、系统实现35%左右、测试5%左右。比例不对就开始检查是不是哪部分写稀了。

6.2 答辩高频知识点与应对思路

答辩老师的关注点其实很固定，无非围绕技术选型、业务逻辑、数据安全、扩展性几个维度反复问。提前把这些问题的答案在脑子里过几遍比什么都管用。

“为什么选这个技术栈？”你的回答主线是：SpringBoot生态成熟上手快、Vue组件化开发适合前后端分离、MySQL轻量可靠满足中小应用场景，三者结合是当前主流的全栈开发技术组合。

“购物车实现原理是什么？”把前端加购、调用后端接口存表、查询回显、下单清空整个链路说清楚。说的时候扫一眼代码位置，显得你不是背稿子。

“订单状态怎么流转的？”从待支付、已支付、已接单、出餐、完成每一步哪里触发状态变更，结合状态机概念说明，能加分说“订单状态用状态字段维护，为确保一致性，所有状态变更都收敛到Service层的统一方法处理”。

“怎么保证数据一致性？”回答方向是数据库事务控制。把下单接口里先查菜品状态、再算价格、再插入订单主表明细、最后清空购物车这些步骤用事务包起来的逻辑讲出来，再补一句“任何一步失败事务回滚”就足够了。

“系统怎么保证安全性？”三层来说：登录鉴权用JWT并设置了过期时间，密码使用加密算法存储，后端接口通过拦截器校验登录状态。

“系统有哪些创新点？”不要凭空编。诚实的思路是：页面交互采用了更符合移动端的触控式设计，购物车加入了菜品状态实时检测，订单管理引入了状态流转机制。说出“与简单CRUD系统相比，我在业务闭环完整性和异常场景处理上做了更多设计”也能过。

还有一个答辩技巧值得注意，把系统启动过程在答辩现场演示一遍加很多分。提前准备好测试数据，现场展示用测试账号点一单，管理员后台接单并修改状态，完整跑通一个购物流程，老师会直观看到系统“能用”。

7. 常见问题与排查技巧实录

7.1 开发环境与数据库连接类问题

“数据库连接失败com.mysql.jdbc.exceptions.jdbc4.CommunicationsException”这类报错是最常见的。第一步检查MySQL服务有没有启动，Windows服务管理器或命令行看3306端口是否在监听。第二步检查连接URL中localhost的配置、用户名和密码和实际是否一致。很多人密码带特殊字符，比如@符号，在YAML配置里要加引号包起来。第三步检查MySQL版本和驱动版本兼容性，MySQL 8.x要用mysql-connector-java 8.x版本的驱动，同时URL要增加时区参数serverTimezone=Asia/Shanghai，否则连接成功也会报时区错误。

另一类常见问题是“Table 'xxx' doesn't exist”或者“Unknown column 'xxx'”。前者是你建表脚本没有在当前连的数据库执行，或者执行的是其他库的脚本。后者是你的实体类和数据库字段对不上，检查驼峰命名映射配置，mybatis-plus里配map-underscore-to-camel-case: true，把数据库下划线字段和Java驼峰属性对应起来。

7.2 前端联调与接口报错类问题

“Access to XMLHttpRequest has been blocked by CORS policy”跨域报错，先检查后端统一跨域配置类有没有生效，再检查是不是Nginx层配置和前端代理重复设置了跨域头，两处都设且值不一致时浏览器拿到的响应可能互相冲突，开发阶段建议只用一种方案。

“接口返回401未登录”，但明明登录成功了。排查思路先后端，用工具直接测试后端接口带Token请求是否正常，正常则说明前端Axios的请求拦截器没生效，一般是Token读取的key对不上，或者响应拦截器拿到401后误清Token导致死循环。

“前端请求路径404”，排查重点看Nginx的location匹配规则。前端请求地址是/api/xxx，如果Nginx里没有这个location配置，请求就到不了后端 8080端口。按上面给的配置模板来就不会出问题。

7.3 业务逻辑运行期问题

购物车加入菜品后数量变成两条而不是合并成一条，检查后端实现时是否用用户ID加菜品ID做了唯一查询，存在则update数量，不存在才insert新记录。这个逻辑叫“存在即更新，不存在即插入”，在Service层写清楚。

订单提交成功但“我的订单”查不到，极可能是订单查询接口没有按用户ID过滤，查了全表数据。检查Controller层取当前登录用户ID的逻辑，要从JWT解析而不是前端传什么就信什么，前端传递的用户ID是可以被篡改的，属于安全漏洞。

菜品修改后前端展示的还是旧图片和旧价格，这种问题一般出在浏览器缓存。在静态资源URL后面拼接版本参数，比如/dish/img/xxx.jpg?v=123456，时间戳变了浏览器就会重新拉取新资源。这个方案在写代码时就要计划进去，不要等出了问题再改。

8. 个人经验与最后叮嘱

我做毕设辅导这些年，见过太多同学把精力全耗在代码上，最后论文稀烂、部署一塌糊涂。其实毕设的评判逻辑更像是一个完整的工程交付：代码能不能跑、论文能不能说清楚、部署文档能不能照着操作成功，三者缺一不可。这套网上点餐系统胜在业务清晰、技术主流、难点可控，完全有实力撑起一篇优秀论文。

最后分享一个很实在的小建议：无论你按照哪一套代码来做，第一件事永远是把数据库脚本先建好跑通，把初始化账号登录进去逛一圈。系统能转，你就有底气继续往下走；系统跑不起来，写再多代码优化都白搭。

希望这篇内容能把你的毕业设计道路铺得平整一些。代码层面遇到具体报错就去搜报错原文，论文层面拿不准就对照我给你列的章节结构来写，答辩前把高频问题过两遍。祝你的毕设顺利通过，答辩时自信讲出让老师点头的系统设计。