酒店自助餐采购与配餐系统的设计与实现这个课题相信不少做毕设的朋友都认真打量过。原因很简单酒店行业本身就是一个“前端体验、后端供应链”的典型场景自助餐更是把食材采购、库存周转、配餐计划、成本控制这些环节全部压缩到一天的运营节奏里。用这套业务做系统设计既能体现数据库建模能力又能呈现前后端交互逻辑还有报表统计、权限控制这些毕设答辩时特别加分的功能点。今天我就把整套系统的设计思路、核心模块拆分、数据库建模过程、以及实际部署时容易踩的坑一次性讲清楚。这套系统具体做什么先给个直观画面酒店餐饮部的采购主管每天打开系统查看各档口热菜档、冷菜档、刺身档、甜品档、水果档提交的次日配餐计划系统根据当前库存量和历史消耗数据自动生成采购建议单采购员拿着建议单去供应商市场比价下单到货后库管员扫码入库到了配餐时间段各档口厨师按配餐计划领料系统实时扣减库存月底财务能看到完整的采购成本分析、食材损耗率、档口配餐执行率。整个链条走通了就是一套标准的餐饮供应链管理系统。我现在把整个项目从设计到实现的完整过程拆开讲从需求分析到数据库设计再到核心代码实现最后是部署上线和调试经验你想复现也好、想改成自己的选题也罢照着这个脉络走基本不会跑偏。1. 项目需求分析与整体架构设计1.1 核心需求到底有哪些做毕设最容易犯的错就是一上来就写代码。这个系统我是先花了大半天时间梳理需求和几个在酒店后厨干过的朋友聊了一圈最终把核心需求收敛成五个功能域采购管理、配餐管理、库存管理、供应商管理、统计报表。采购管理不是简单的“提交采购单”就完了它得支持采购计划的生成、供应商比价、采购订单的状态流转草稿→待审核→审核通过→已下单→已到货→已入库。配餐管理要能按日期、按档口配置菜品计划每条配餐计划会自动计算需要的食材数量减去当前可用库存差值就是需要采购的量。库存管理要处理入库、出库、退库、报损四种单据还要预警低于安全库存的食材。供应商管理维护供应商档案、供应品类、历史报价方便采购比价。统计报表围绕采购成本、食材损耗、档口领料情况、月度经营分析做图表展示。这些需求确定以后再做技术选型。我选的是Spring Boot MyBatis Plus Vue MySQL这套组合理由后面讲。1.2 为什么选Spring Boot Vue这套技术栈技术选型不是越新越好也不是越复杂显得越有水平而是要让答辩老师一眼看出你“懂业务”知道应用场景需要什么知道每种技术的边界在哪。后端用Spring Boot 2.7理由说白了就三点第一Spring Boot的自动配置和starter机制能极大减少配置代码对于一个以业务逻辑为主、不想在环境搭建上浪费太多精力的毕设项目这太友好了第二Spring Security加JWT做认证授权是行业标准做法安全相关的代码网上资料多、靠谱方案也多出了问题好查第三Spring生态和MyBatis Plus配合度高分页、条件构造器这类高频操作可以省掉大量样板代码。前端选了Vue 2 Element UI。Vue 2虽然官方进入维护后期但对于毕设场景反而更稳Element UI组件库在后台管理类系统里的成熟度是独一档的存在表格的筛选排序、表单校验、弹窗交互能直接复用成熟组件不用自己造轮子。数据库用MySQL 8.0存储引擎用InnoDB事务隔离级别用默认的REPEATABLE READ。为什么不用PostgreSQL不是它不好而是国内大部分论文资料、网上教程都以MySQL为背景讲遇到问题时检索效率完全不同。OR/M框架选MyBatis Plus而不是JPA核心考量是复杂的统计查询比如按月分档口的采购金额汇总写SQL更直观可控JPA在这类自定义查询里反而绕。1.3 整体架构分层设计系统采用经典的前后端分离架构掉用链路上分为四层浏览器端是Vue单页应用通过Axios发HTTP请求网关层由Nginx做静态资源托管和API反向代理解决跨域和动静分离问题应用层是Spring Boot的Controller-Service-Mapper分层结构业务逻辑在Service层处理事务边界划在这里数据层全部落在MySQL。Redis在这里只做JWT Token的刷新和验证缓存暂时不做复杂的缓存策略毕竟是教学项目不要让分布式缓存喧宾夺主。前端项目结构按“视图-组件-API”组织views目录下按业务模块分目录每个页面拆分成可复用的子组件API请求按模块封装成独立js文件。后端项目按“controller-service-mapper-entity”四层分包entity对应数据库表结构vo存放接口返回给前端的封装对象dto接收前端传参。这套分包规范很关键它直接影响代码审查时的观感——答辩老师可能会当场打开你的项目看代码结构一个清晰的分层比注释写得天花乱坠都更有说服力。前端部署在8080端口由Nginx托管后端启动在8081端口Nginx配置/api/前缀的所有请求转发到后端服务。开发环境下用Vue CLI的devServer代理做同样的事保证前后端联调时不用纠结跨域。2. 数据库设计这套系统的灵魂所在数据库设计是这套系统最值得花时间的地方。很多毕设的表结构撑不过第三轮问答就是因为表设计得太朴素要么直接一张大表塞所有字段要么没有状态字段无法支撑流程流转。采购配餐系统有一个很典型的特征业务数据之间有较强的依赖关系而且金额和数量需要保持严格一致所以设计上必须遵循范式规范同时在部分报表场景做冗余优化。2.1 核心数据表全景整个系统一共设计了11张核心业务表外加3张基础权限表用户、角色、菜单。先把业务表列出来大致分成四类一类是主数据表包括供应商表supplier和食材信息表ingredient。食材表需要记录每个食材的默认单位千克、升、个、安全库存阈值、当前库存量和最近采购价这些字段会直接影响采购建议的计算逻辑。一类是采购域表包括采购单主表purchase_order和采购单明细表purchase_order_item。主表只存采购单号、供应商ID、采购总金额、状态、制单人、审核人等汇总信息明细表逐行记录每种食材的采购数量、单价、金额。为什么拆两张表因为一张采购单必然对应多条食材记录主表负责管理单据生命周期明细表负责记录具体品类两张表通过外键关联并在事务中同时写入。一类是配餐域表包括配餐计划主表meal_plan、配餐计划明细表meal_plan_item、档口表station。档口表维护热菜、冷菜、刺身、甜品、水果等基础档口配餐计划按档口和日期进行配置明细表记录每道菜品的食材用量。一类是库存域表包括入库单stock_in、入库明细stock_in_item、出库单stock_out、出库明细stock_out_item、库存流水表stock_flow。库存流水表是这套设计里比较亮眼的地方所有入库、出库、报损、盘点差异都会生成一条流水记录既能追溯操作历史也为后续校验账面库存和实际库存的一致性提供数据基础。2.2 关键表结构说明我拿配餐计划明细表举例这张表是采购建议的核心数据来源设计的好坏直接影响业务流转效果CREATE TABLE meal_plan_item ( id BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT 主键, plan_id BIGINT NOT NULL COMMENT 配餐计划主表ID, station_id BIGINT NOT NULL COMMENT 档口ID, dish_name VARCHAR(100) NOT NULL COMMENT 菜品名称, ingredient_id BIGINT NOT NULL COMMENT 食材ID, quantity DECIMAL(10,2) NOT NULL COMMENT 计划用量, unit VARCHAR(20) NOT NULL COMMENT 单位, estimated_cost DECIMAL(10,2) DEFAULT 0 COMMENT 预估成本, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT配餐计划明细表;字段类型这里有一个细节数量字段用DECIMAL(10,2)而不用FLOAT或DOUBLE。原因很简单浮点数在计算机里的二进制表示会产生精度误差涉及金额和库存数量时绝对不能用浮点类型存否则累计到月底对账时几毛钱、几克肉的差异会让你怀疑自己数学是体育老师教的。DECIMAL是字符串存储的定点数不会有这个问题。另一个细节是外键。我没在数据库层面建物理外键而是在应用层通过逻辑关联约束。这样做的考虑是物理外键在删除数据时需要额外的约束检查和维护成本在真实的业务场景中很多团队默认禁用物理外键用代码保证数据一致性。但是表与表之间的关联关系必须清晰体现在ER图中这个答辩时会重点讲。2.3 采购建议的自动生成逻辑这个功能是整套系统的业务亮点我单独拎出来讲。它的核心价值是配餐计划一旦确定系统能自动算出来当天需要买什么、买多少减少人工统计的工作量和出错率。逻辑本质上就是一条公式建议采购量 配餐计划消耗量 - 当前可用库存 安全库存。具体流程是前端先确定日期和档口创建配餐计划主表记录然后逐条添加菜品和对应食材用量写入明细表每次写入明细表时后端Service层做一次实时计算——查当前库存表得到该食材的库存量把计划内所有明细表中该食材的需求量汇总再做差计算得到“建议采购量”字段写入日志并随时反馈到前端界面。这里有个易踩的坑同一种食材可能出现在不同档口的多个菜品里比如鸡蛋早餐档的煎蛋、热菜档的番茄炒蛋、甜品档的蛋糕都可能用到如果只按单条配餐记录去计算采购建议采购量必然偏小。所以汇总时必须按ingredient_id做归组把同一食材在全部计划内的需求量累加后再减库存。这个细节可以在答辩时主动讲属于体现业务思考的加分点。库存流转这里还有一个核心约束转折点一致性。入库时库存表的库存量增加同时往库存流水表写入一条流水出库时同理库存减少流水增加任何添加、修改、删除库存单据的操作都必须包裹在一个事务中要么全部成功、要么全部回滚这能有效防止数据不一致的情况。3. 前后端核心功能实现3.1 后端接口设计与实现思路后端接口遵循RESTful风格统一返回体定义为Result对象包含code、message、data三个字段。请求成功的code是200业务异常的code按模块划分采购域异常从30001开始库存域异常从30002开始配餐域异常从30003开始。这样设计的好处是前端拿code就能快速定位报错来源全局异常处理器统一拦截不用每层代码里写重复的try-catch。权限控制用JWT加拦截器实现。用户登录成功后后端生成一个有效期为两小时的token返回给前端。前端把token存到localStorage每次请求在Axios拦截器里加到Authorization请求头。后端写一个HandlerInterceptor对非白名单路径统一校验token的有效性和过期时间。用户角色分三种采购员、库管员、管理员权限控制粒度到接口级别。一个需要注意的点前端不要只根据token判断用户是否登录因为JWT服务端是无状态的token过期后前端如果不主动处理接口返回401就会产生一堆莫名其妙的报错。所以前端Axios统一响应拦截器里必须写一段逻辑当HTTP状态码是401时清掉本地token并跳转到登录页。3.2 前端页面关键模块的实现前端不是简单的页面堆叠而是把流程串起来的操作台。我按使用频率和业务重要程度排个序最高频的页面是配餐计划、采购审核、库存管理、统计报表。配餐计划页页面左侧是档口列表右侧是计划表格。用户先选日期和档口表格自动加载已有计划新增菜品时有一个联动选择器选中菜品后自动带出每份所需食材填入份数后系统自动算总用量。每次操作后页面上方会显示一段实时的采购建议汇总这段汇总就是从后端/api/plan/suggestion接口拉取的。采购审核页采购主管登录后看到所有状态为“待审核”的采购单点击进入详情能看到每条食材的采购数量、上周平均采购价、当前供应商报价确认无误后点“审核通过”也可以填写驳回原因。这个页面的交互逻辑很直接但数据展示是从多表关联查询聚合出来的后端SQL的编写量不小是联调时最容易出bug的地方。库存管理页库存列表默认显示所有食材的实时库存、安全库存、库存状态正常、偏低、告急。告急的食材行标红提醒点击“入库”或“出库”按钮弹出单据录入框。这里的核心技术点在于处理库存流水的事务逻辑一个入库单保存成功后需要同时更新库存表数量、写入库存流水表、更新食材表的最近采购价三个操作必须在同一个事务里完成。统计报表页使用ECharts做图表展示采购成本按月走势折线图、各档口领料占比环形图、食材损耗排行柱状图。报表的数据来源是后端统计SQL按日期、档口、食材分组聚合前端只负责把后端返回的数据结构映射成ECharts的option。这里要提前想好数据结构的命名规范否则前后端联调需要反复改字段名很浪费时间。3.3 盘点表单联调的一个经验前后端联调阶段最大的敌人不是逻辑难度而是字段命名不一致。我和很多朋友交流过这几乎是所有毕设项目都会踩的坑。后端返回purchaseNum前端以为字段叫purchaseNumber结果页面上显示undefined后端返回createTime前端取created_at又对不上。解决方法是联调前先做一次接口文档对表。不用动用Swagger或Postman的复杂功能简单点在前后端各放一份字段对照表把接口名、请求参数、返回参数、字段类型列清楚逐条过一遍。我是用Excel维护的字段名有改动时两边同步更新基本杜绝了这类低级错误。另外接口返回的数据结构如果有多层嵌套比如采购单详情包括主表信息和明细列表建议返回给前端时包装成统一结构{ code: 200, message: success, data: { purchaseOrder: {...主表字段...}, items: [...明细列表...] } }前端的采购单详情页一次拉取即可渲染整页数据不用先查主表再根据主表ID逐条查明细少了很多异步请求的时序问题。4. 项目部署与常见问题排查4.1 本地环境搭建与启动步骤这个项目相关的运行环境其实很简单就四样JDK 1.8及以上我用的是1.8、Maven 3.6、MySQL 8.0、Node.js 14。下面的步骤是我实际操作的完整流程照着走基本半小时内能跑起来。先创建数据库并导入初始化脚本。初始化脚本里包含建库语句、建表语句、初始管理员账号和基础菜单数据。注意MySQL连接串必须显式指定characterEncodingutf8和serverTimezoneAsia/Shanghai否则插入中文可能出现乱码日期时间也可能因为时区差八个小时而出现诡异错位spring.datasource.urljdbc:mysql://localhost:3306/hotel_buffet?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai spring.datasource.usernameroot spring.datasource.password你的密码后端启动前先在根目录执行mvn clean package -DskipTests打包然后跑java -jar target/hotel-buffet-0.0.1-SNAPSHOT.jar。前端在vue目录下执行npm install装依赖然后npm run serve启动开发服务器。开发环境下前端通过vue.config.js里的devServer代理把/api请求转发到localhost:8081所以前端页面里写的请求路径全部以/api开头即可不需要写完整的后端地址。第一次启动时容易出错的是MyBatis Plus的Mapper扫描。确认启动类上加了MapperScan(com.example.mapper)注解否则会报Invalid bound statement (not found)。这个错误是因为Mapper接口没有正确注册不是什么玄学问题把包路径对上了就好。4.2 部署时容易踩的坑我把实际部署中遇到过的、以及帮别人排查过的几个高频问题整理成速查表基本覆盖了大部分“起不来”的情况常见现象最可能的原因解决办法接口报404但Controller存在请求路径的上下文前缀不一致检查server.servlet.context-path配置前端代理前缀需对应前后端联调CORS报错后端没配置跨域过滤器Spring Boot写一个CorsFilter允许http://localhost:8080调用中文乱码MySQL连接串没指定编码连接串加characterEncodingutf8和useUnicodetrue日期显示相差8小时时区未指定连接串加serverTimezoneAsia/ShanghaiJackson设置统一时区打包后jar包启动报数据库连不上数据库地址写的是localhost但部署环境是远程库使用环境变量注入数据库连接信息不要硬编码还有一个很关键但容易被忽略的点Vue前端路由如果用了history模式Nginx部署时必须配置try_files回退到index.html否则刷新页面就是404。推荐直接用hash模式毕设答辩演示时刷新页面更稳省去Nginx配置的麻烦。4.3 答辩前必须自查的三个核心问题答辩老师不太可能在你讲完演示后只是点头微笑一定会深挖系统里的几个关键点。我建议提交前自问一下下面几个问题每个都能讲出完整逻辑的话答辩这段基本稳了。第一个问题是采购建议的具体计算流程是怎样的不要回答“系统自动生成”就结束。要能说清楚某天某个档口添加了一道菜品消耗鸡蛋2千克系统查出当前鸡蛋库存5千克其他档口当日计划中鸡蛋还要用3千克安全库存设为2千克那么建议采购量就是232-52千克。这套逻辑自己用真实数据走一遍心里有底。第二个问题是数据库的事务控制是怎么设计的要能指出入库单保存时调用的Service方法标注了Transactional因为同时更新库存表、写流水表、更新食材表任何一个失败都会导致数据和实际业务不一致。如果再展开一点可以提REPEATABLE READ级别下并发创建采购单时行锁如何保证两条明细不会写花这个深度足以体现你的思考。第三个问题是项目的难点和亮点分别是什么不建议说什么“功能全面、界面美观”这种没有区分度的答案。可以说难点在于多档口共用食材导致采购量汇总逻辑需要考虑跨档口的去重与聚合亮点在于库存流水表贯穿所有出入库单据配合库存表能随时回溯每一次库存变动。这些都是做项目过程中真实遇到、认真解决过的事情讲出来自然有说服力。5. 这套系统后续还能怎么扩展做毕设的时候整体功能已经闭环但退一步想这套系统的骨架其实是支持往更多方向发展的。我自己事后复盘过可扩展的方向大致有这么几个一个是移动端适配。目前的Vue后台是PC端设计酒店采购主管在路上、在仓库随时需要处理紧急补货单移动端H5或者微信小程序会是真实场景的自然延伸。因为后端接口都是RESTful的理论上只需要新增一套前端界面后端业务逻辑可以原样复用工作量主要集中在移动端的交互设计上。一个是供应商在线报价。目前的比价方式是采购员电话或线下询价后再录入系统如果让供应商自己登录系统维护报价单采购员直接在系统内对比价格、生成订单整个采购流程会更顺。技术上的变化主要是新增供应商角色、报价表、操作日志原有采购审核逻辑可以保持不动。一个是数据层面的经营分析增强。现在的报表以固定图表为主如果能加一个基于历史数据的采购价格波动预测或者对档口餐品做销量和消耗排名分析对酒店管理层会更有参考价值。这个方向偏向数据分析本质上是用ECharts现有能力做的可视化不涉及新的技术体系。最后说一下这套系统的源码结构。我把源码按后端、前端、数据库脚本三部分分开存放后端是标准的Spring Boot工程前端是Vue CLI工程数据库脚本包括初始化表和测试数据。相关模块的配置文件和数据库脚本说明都写在项目根目录的README里。你按着顺序跑一遍应该能顺利把系统启动起来再对照本文的设计思路去读代码理解成本就会低很多。如果你正在做类似的选题希望这些细节能帮你少踩几个坑把更多精力放到真正有思考深度的部分去。我做这个项目的最大感受是功能做完只是及格能讲清楚每个设计决策背后的理由才是真正加分的地方。 基于Spring Boot与Vue的酒店自助餐采购配餐系统设计与实现
酒店自助餐采购与配餐系统的设计与实现这个课题相信不少做毕设的朋友都认真打量过。原因很简单酒店行业本身就是一个“前端体验、后端供应链”的典型场景自助餐更是把食材采购、库存周转、配餐计划、成本控制这些环节全部压缩到一天的运营节奏里。用这套业务做系统设计既能体现数据库建模能力又能呈现前后端交互逻辑还有报表统计、权限控制这些毕设答辩时特别加分的功能点。今天我就把整套系统的设计思路、核心模块拆分、数据库建模过程、以及实际部署时容易踩的坑一次性讲清楚。这套系统具体做什么先给个直观画面酒店餐饮部的采购主管每天打开系统查看各档口热菜档、冷菜档、刺身档、甜品档、水果档提交的次日配餐计划系统根据当前库存量和历史消耗数据自动生成采购建议单采购员拿着建议单去供应商市场比价下单到货后库管员扫码入库到了配餐时间段各档口厨师按配餐计划领料系统实时扣减库存月底财务能看到完整的采购成本分析、食材损耗率、档口配餐执行率。整个链条走通了就是一套标准的餐饮供应链管理系统。我现在把整个项目从设计到实现的完整过程拆开讲从需求分析到数据库设计再到核心代码实现最后是部署上线和调试经验你想复现也好、想改成自己的选题也罢照着这个脉络走基本不会跑偏。1. 项目需求分析与整体架构设计1.1 核心需求到底有哪些做毕设最容易犯的错就是一上来就写代码。这个系统我是先花了大半天时间梳理需求和几个在酒店后厨干过的朋友聊了一圈最终把核心需求收敛成五个功能域采购管理、配餐管理、库存管理、供应商管理、统计报表。采购管理不是简单的“提交采购单”就完了它得支持采购计划的生成、供应商比价、采购订单的状态流转草稿→待审核→审核通过→已下单→已到货→已入库。配餐管理要能按日期、按档口配置菜品计划每条配餐计划会自动计算需要的食材数量减去当前可用库存差值就是需要采购的量。库存管理要处理入库、出库、退库、报损四种单据还要预警低于安全库存的食材。供应商管理维护供应商档案、供应品类、历史报价方便采购比价。统计报表围绕采购成本、食材损耗、档口领料情况、月度经营分析做图表展示。这些需求确定以后再做技术选型。我选的是Spring Boot MyBatis Plus Vue MySQL这套组合理由后面讲。1.2 为什么选Spring Boot Vue这套技术栈技术选型不是越新越好也不是越复杂显得越有水平而是要让答辩老师一眼看出你“懂业务”知道应用场景需要什么知道每种技术的边界在哪。后端用Spring Boot 2.7理由说白了就三点第一Spring Boot的自动配置和starter机制能极大减少配置代码对于一个以业务逻辑为主、不想在环境搭建上浪费太多精力的毕设项目这太友好了第二Spring Security加JWT做认证授权是行业标准做法安全相关的代码网上资料多、靠谱方案也多出了问题好查第三Spring生态和MyBatis Plus配合度高分页、条件构造器这类高频操作可以省掉大量样板代码。前端选了Vue 2 Element UI。Vue 2虽然官方进入维护后期但对于毕设场景反而更稳Element UI组件库在后台管理类系统里的成熟度是独一档的存在表格的筛选排序、表单校验、弹窗交互能直接复用成熟组件不用自己造轮子。数据库用MySQL 8.0存储引擎用InnoDB事务隔离级别用默认的REPEATABLE READ。为什么不用PostgreSQL不是它不好而是国内大部分论文资料、网上教程都以MySQL为背景讲遇到问题时检索效率完全不同。OR/M框架选MyBatis Plus而不是JPA核心考量是复杂的统计查询比如按月分档口的采购金额汇总写SQL更直观可控JPA在这类自定义查询里反而绕。1.3 整体架构分层设计系统采用经典的前后端分离架构掉用链路上分为四层浏览器端是Vue单页应用通过Axios发HTTP请求网关层由Nginx做静态资源托管和API反向代理解决跨域和动静分离问题应用层是Spring Boot的Controller-Service-Mapper分层结构业务逻辑在Service层处理事务边界划在这里数据层全部落在MySQL。Redis在这里只做JWT Token的刷新和验证缓存暂时不做复杂的缓存策略毕竟是教学项目不要让分布式缓存喧宾夺主。前端项目结构按“视图-组件-API”组织views目录下按业务模块分目录每个页面拆分成可复用的子组件API请求按模块封装成独立js文件。后端项目按“controller-service-mapper-entity”四层分包entity对应数据库表结构vo存放接口返回给前端的封装对象dto接收前端传参。这套分包规范很关键它直接影响代码审查时的观感——答辩老师可能会当场打开你的项目看代码结构一个清晰的分层比注释写得天花乱坠都更有说服力。前端部署在8080端口由Nginx托管后端启动在8081端口Nginx配置/api/前缀的所有请求转发到后端服务。开发环境下用Vue CLI的devServer代理做同样的事保证前后端联调时不用纠结跨域。2. 数据库设计这套系统的灵魂所在数据库设计是这套系统最值得花时间的地方。很多毕设的表结构撑不过第三轮问答就是因为表设计得太朴素要么直接一张大表塞所有字段要么没有状态字段无法支撑流程流转。采购配餐系统有一个很典型的特征业务数据之间有较强的依赖关系而且金额和数量需要保持严格一致所以设计上必须遵循范式规范同时在部分报表场景做冗余优化。2.1 核心数据表全景整个系统一共设计了11张核心业务表外加3张基础权限表用户、角色、菜单。先把业务表列出来大致分成四类一类是主数据表包括供应商表supplier和食材信息表ingredient。食材表需要记录每个食材的默认单位千克、升、个、安全库存阈值、当前库存量和最近采购价这些字段会直接影响采购建议的计算逻辑。一类是采购域表包括采购单主表purchase_order和采购单明细表purchase_order_item。主表只存采购单号、供应商ID、采购总金额、状态、制单人、审核人等汇总信息明细表逐行记录每种食材的采购数量、单价、金额。为什么拆两张表因为一张采购单必然对应多条食材记录主表负责管理单据生命周期明细表负责记录具体品类两张表通过外键关联并在事务中同时写入。一类是配餐域表包括配餐计划主表meal_plan、配餐计划明细表meal_plan_item、档口表station。档口表维护热菜、冷菜、刺身、甜品、水果等基础档口配餐计划按档口和日期进行配置明细表记录每道菜品的食材用量。一类是库存域表包括入库单stock_in、入库明细stock_in_item、出库单stock_out、出库明细stock_out_item、库存流水表stock_flow。库存流水表是这套设计里比较亮眼的地方所有入库、出库、报损、盘点差异都会生成一条流水记录既能追溯操作历史也为后续校验账面库存和实际库存的一致性提供数据基础。2.2 关键表结构说明我拿配餐计划明细表举例这张表是采购建议的核心数据来源设计的好坏直接影响业务流转效果CREATE TABLE meal_plan_item ( id BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT 主键, plan_id BIGINT NOT NULL COMMENT 配餐计划主表ID, station_id BIGINT NOT NULL COMMENT 档口ID, dish_name VARCHAR(100) NOT NULL COMMENT 菜品名称, ingredient_id BIGINT NOT NULL COMMENT 食材ID, quantity DECIMAL(10,2) NOT NULL COMMENT 计划用量, unit VARCHAR(20) NOT NULL COMMENT 单位, estimated_cost DECIMAL(10,2) DEFAULT 0 COMMENT 预估成本, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT配餐计划明细表;字段类型这里有一个细节数量字段用DECIMAL(10,2)而不用FLOAT或DOUBLE。原因很简单浮点数在计算机里的二进制表示会产生精度误差涉及金额和库存数量时绝对不能用浮点类型存否则累计到月底对账时几毛钱、几克肉的差异会让你怀疑自己数学是体育老师教的。DECIMAL是字符串存储的定点数不会有这个问题。另一个细节是外键。我没在数据库层面建物理外键而是在应用层通过逻辑关联约束。这样做的考虑是物理外键在删除数据时需要额外的约束检查和维护成本在真实的业务场景中很多团队默认禁用物理外键用代码保证数据一致性。但是表与表之间的关联关系必须清晰体现在ER图中这个答辩时会重点讲。2.3 采购建议的自动生成逻辑这个功能是整套系统的业务亮点我单独拎出来讲。它的核心价值是配餐计划一旦确定系统能自动算出来当天需要买什么、买多少减少人工统计的工作量和出错率。逻辑本质上就是一条公式建议采购量 配餐计划消耗量 - 当前可用库存 安全库存。具体流程是前端先确定日期和档口创建配餐计划主表记录然后逐条添加菜品和对应食材用量写入明细表每次写入明细表时后端Service层做一次实时计算——查当前库存表得到该食材的库存量把计划内所有明细表中该食材的需求量汇总再做差计算得到“建议采购量”字段写入日志并随时反馈到前端界面。这里有个易踩的坑同一种食材可能出现在不同档口的多个菜品里比如鸡蛋早餐档的煎蛋、热菜档的番茄炒蛋、甜品档的蛋糕都可能用到如果只按单条配餐记录去计算采购建议采购量必然偏小。所以汇总时必须按ingredient_id做归组把同一食材在全部计划内的需求量累加后再减库存。这个细节可以在答辩时主动讲属于体现业务思考的加分点。库存流转这里还有一个核心约束转折点一致性。入库时库存表的库存量增加同时往库存流水表写入一条流水出库时同理库存减少流水增加任何添加、修改、删除库存单据的操作都必须包裹在一个事务中要么全部成功、要么全部回滚这能有效防止数据不一致的情况。3. 前后端核心功能实现3.1 后端接口设计与实现思路后端接口遵循RESTful风格统一返回体定义为Result对象包含code、message、data三个字段。请求成功的code是200业务异常的code按模块划分采购域异常从30001开始库存域异常从30002开始配餐域异常从30003开始。这样设计的好处是前端拿code就能快速定位报错来源全局异常处理器统一拦截不用每层代码里写重复的try-catch。权限控制用JWT加拦截器实现。用户登录成功后后端生成一个有效期为两小时的token返回给前端。前端把token存到localStorage每次请求在Axios拦截器里加到Authorization请求头。后端写一个HandlerInterceptor对非白名单路径统一校验token的有效性和过期时间。用户角色分三种采购员、库管员、管理员权限控制粒度到接口级别。一个需要注意的点前端不要只根据token判断用户是否登录因为JWT服务端是无状态的token过期后前端如果不主动处理接口返回401就会产生一堆莫名其妙的报错。所以前端Axios统一响应拦截器里必须写一段逻辑当HTTP状态码是401时清掉本地token并跳转到登录页。3.2 前端页面关键模块的实现前端不是简单的页面堆叠而是把流程串起来的操作台。我按使用频率和业务重要程度排个序最高频的页面是配餐计划、采购审核、库存管理、统计报表。配餐计划页页面左侧是档口列表右侧是计划表格。用户先选日期和档口表格自动加载已有计划新增菜品时有一个联动选择器选中菜品后自动带出每份所需食材填入份数后系统自动算总用量。每次操作后页面上方会显示一段实时的采购建议汇总这段汇总就是从后端/api/plan/suggestion接口拉取的。采购审核页采购主管登录后看到所有状态为“待审核”的采购单点击进入详情能看到每条食材的采购数量、上周平均采购价、当前供应商报价确认无误后点“审核通过”也可以填写驳回原因。这个页面的交互逻辑很直接但数据展示是从多表关联查询聚合出来的后端SQL的编写量不小是联调时最容易出bug的地方。库存管理页库存列表默认显示所有食材的实时库存、安全库存、库存状态正常、偏低、告急。告急的食材行标红提醒点击“入库”或“出库”按钮弹出单据录入框。这里的核心技术点在于处理库存流水的事务逻辑一个入库单保存成功后需要同时更新库存表数量、写入库存流水表、更新食材表的最近采购价三个操作必须在同一个事务里完成。统计报表页使用ECharts做图表展示采购成本按月走势折线图、各档口领料占比环形图、食材损耗排行柱状图。报表的数据来源是后端统计SQL按日期、档口、食材分组聚合前端只负责把后端返回的数据结构映射成ECharts的option。这里要提前想好数据结构的命名规范否则前后端联调需要反复改字段名很浪费时间。3.3 盘点表单联调的一个经验前后端联调阶段最大的敌人不是逻辑难度而是字段命名不一致。我和很多朋友交流过这几乎是所有毕设项目都会踩的坑。后端返回purchaseNum前端以为字段叫purchaseNumber结果页面上显示undefined后端返回createTime前端取created_at又对不上。解决方法是联调前先做一次接口文档对表。不用动用Swagger或Postman的复杂功能简单点在前后端各放一份字段对照表把接口名、请求参数、返回参数、字段类型列清楚逐条过一遍。我是用Excel维护的字段名有改动时两边同步更新基本杜绝了这类低级错误。另外接口返回的数据结构如果有多层嵌套比如采购单详情包括主表信息和明细列表建议返回给前端时包装成统一结构{ code: 200, message: success, data: { purchaseOrder: {...主表字段...}, items: [...明细列表...] } }前端的采购单详情页一次拉取即可渲染整页数据不用先查主表再根据主表ID逐条查明细少了很多异步请求的时序问题。4. 项目部署与常见问题排查4.1 本地环境搭建与启动步骤这个项目相关的运行环境其实很简单就四样JDK 1.8及以上我用的是1.8、Maven 3.6、MySQL 8.0、Node.js 14。下面的步骤是我实际操作的完整流程照着走基本半小时内能跑起来。先创建数据库并导入初始化脚本。初始化脚本里包含建库语句、建表语句、初始管理员账号和基础菜单数据。注意MySQL连接串必须显式指定characterEncodingutf8和serverTimezoneAsia/Shanghai否则插入中文可能出现乱码日期时间也可能因为时区差八个小时而出现诡异错位spring.datasource.urljdbc:mysql://localhost:3306/hotel_buffet?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai spring.datasource.usernameroot spring.datasource.password你的密码后端启动前先在根目录执行mvn clean package -DskipTests打包然后跑java -jar target/hotel-buffet-0.0.1-SNAPSHOT.jar。前端在vue目录下执行npm install装依赖然后npm run serve启动开发服务器。开发环境下前端通过vue.config.js里的devServer代理把/api请求转发到localhost:8081所以前端页面里写的请求路径全部以/api开头即可不需要写完整的后端地址。第一次启动时容易出错的是MyBatis Plus的Mapper扫描。确认启动类上加了MapperScan(com.example.mapper)注解否则会报Invalid bound statement (not found)。这个错误是因为Mapper接口没有正确注册不是什么玄学问题把包路径对上了就好。4.2 部署时容易踩的坑我把实际部署中遇到过的、以及帮别人排查过的几个高频问题整理成速查表基本覆盖了大部分“起不来”的情况常见现象最可能的原因解决办法接口报404但Controller存在请求路径的上下文前缀不一致检查server.servlet.context-path配置前端代理前缀需对应前后端联调CORS报错后端没配置跨域过滤器Spring Boot写一个CorsFilter允许http://localhost:8080调用中文乱码MySQL连接串没指定编码连接串加characterEncodingutf8和useUnicodetrue日期显示相差8小时时区未指定连接串加serverTimezoneAsia/ShanghaiJackson设置统一时区打包后jar包启动报数据库连不上数据库地址写的是localhost但部署环境是远程库使用环境变量注入数据库连接信息不要硬编码还有一个很关键但容易被忽略的点Vue前端路由如果用了history模式Nginx部署时必须配置try_files回退到index.html否则刷新页面就是404。推荐直接用hash模式毕设答辩演示时刷新页面更稳省去Nginx配置的麻烦。4.3 答辩前必须自查的三个核心问题答辩老师不太可能在你讲完演示后只是点头微笑一定会深挖系统里的几个关键点。我建议提交前自问一下下面几个问题每个都能讲出完整逻辑的话答辩这段基本稳了。第一个问题是采购建议的具体计算流程是怎样的不要回答“系统自动生成”就结束。要能说清楚某天某个档口添加了一道菜品消耗鸡蛋2千克系统查出当前鸡蛋库存5千克其他档口当日计划中鸡蛋还要用3千克安全库存设为2千克那么建议采购量就是232-52千克。这套逻辑自己用真实数据走一遍心里有底。第二个问题是数据库的事务控制是怎么设计的要能指出入库单保存时调用的Service方法标注了Transactional因为同时更新库存表、写流水表、更新食材表任何一个失败都会导致数据和实际业务不一致。如果再展开一点可以提REPEATABLE READ级别下并发创建采购单时行锁如何保证两条明细不会写花这个深度足以体现你的思考。第三个问题是项目的难点和亮点分别是什么不建议说什么“功能全面、界面美观”这种没有区分度的答案。可以说难点在于多档口共用食材导致采购量汇总逻辑需要考虑跨档口的去重与聚合亮点在于库存流水表贯穿所有出入库单据配合库存表能随时回溯每一次库存变动。这些都是做项目过程中真实遇到、认真解决过的事情讲出来自然有说服力。5. 这套系统后续还能怎么扩展做毕设的时候整体功能已经闭环但退一步想这套系统的骨架其实是支持往更多方向发展的。我自己事后复盘过可扩展的方向大致有这么几个一个是移动端适配。目前的Vue后台是PC端设计酒店采购主管在路上、在仓库随时需要处理紧急补货单移动端H5或者微信小程序会是真实场景的自然延伸。因为后端接口都是RESTful的理论上只需要新增一套前端界面后端业务逻辑可以原样复用工作量主要集中在移动端的交互设计上。一个是供应商在线报价。目前的比价方式是采购员电话或线下询价后再录入系统如果让供应商自己登录系统维护报价单采购员直接在系统内对比价格、生成订单整个采购流程会更顺。技术上的变化主要是新增供应商角色、报价表、操作日志原有采购审核逻辑可以保持不动。一个是数据层面的经营分析增强。现在的报表以固定图表为主如果能加一个基于历史数据的采购价格波动预测或者对档口餐品做销量和消耗排名分析对酒店管理层会更有参考价值。这个方向偏向数据分析本质上是用ECharts现有能力做的可视化不涉及新的技术体系。最后说一下这套系统的源码结构。我把源码按后端、前端、数据库脚本三部分分开存放后端是标准的Spring Boot工程前端是Vue CLI工程数据库脚本包括初始化表和测试数据。相关模块的配置文件和数据库脚本说明都写在项目根目录的README里。你按着顺序跑一遍应该能顺利把系统启动起来再对照本文的设计思路去读代码理解成本就会低很多。如果你正在做类似的选题希望这些细节能帮你少踩几个坑把更多精力放到真正有思考深度的部分去。我做这个项目的最大感受是功能做完只是及格能讲清楚每个设计决策背后的理由才是真正加分的地方。