又到毕业设计选题季每年这个时候我都会收到一堆私信来问“Spring Boot 餐饮管理系统到底怎么做”。这个题目确实是计算机专业毕设里的常青树选它的人多坑也多——版本环境对不上、数据库设计一团乱、前后端联调跨域报错、答辩时被老师问住性能瓶颈。今天我就把这个题目从选题定位、技术选型、数据库设计、核心功能实现到部署上线和答辩准备一次性讲透结合我带过的项目经验和实际踩过的坑给准备做这个题目的同学一份可以直接抄作业的全流程参考。这篇内容适合三类人看一是正在为毕设选题发愁的计算机专业学生二是打算用 Spring Boot 练手做一个完整业务系统的初级开发者三是想了解餐饮管理系统后台到底怎么设计的产品和测试同学。我会尽量把每个环节为什么这么做讲清楚而不是只丢一堆代码和配置。1. 项目整体设计与技术选型思路1.1 为什么餐饮管理系统是毕设的稳妥之选选毕设题目核心就三条业务逻辑自己能讲明白、技术栈能覆盖主流知识点、工作量在三个月内能完成。餐饮管理系统恰好全中。它不像电商系统那样涉及复杂的支付分账和物流状态机也不像社交产品那样要处理高并发实时消息但它的业务闭环非常完整——从客户扫码点餐、后厨接单出餐、前台结账到菜品管理、库存预警、营业报表每个环节都有清晰的数据流转和状态变化。这种“麻雀虽小五脏俱全”的特性意味着你在答辩时能很自然地把整个业务流程串起来讲不用背稿子。更实际的一点是餐饮管理系统的需求可以自由裁剪。时间紧就做基础的点餐、订单、菜品模块时间充裕就再加桌台管理、会员营销、库存预警、数据可视化。它天然支持从低到高的复杂度扩展完全可以根据自己的进度动态调整范围。我做毕设指导这些年最容易翻车的反而是那些一开始就把题目定得很大的同学比如“基于微服务的电商平台”最后PPT里全是概念没有一个能跑通的完整链路。餐饮管理系统就很少出现这种情况。1.2 技术栈怎么选Spring Boot 2.7 MyBatis-Plus Vue 3技术栈的选择直接决定你后面三个月是高效开发还是天天配环境。这个项目的组合我比较推荐后端Spring Boot 2.7.x MyBatis-Plus 3.5.x MySQL 5.7/8.0 Redis前端Vue 3 Element Plus Axios Vite鉴权JWT 拦截器构建Maven部署Docker Nginx先说版本。我见过太多人一上来就装 Spring Boot 3.2然后发现网上教程全是 2.x 的写法javax 包改成 jakarta一堆老依赖废掉光改报错就花了一周。对于毕设来说Spring Boot 2.7 是最稳的版本本地环境用 JDK 8 或 JDK 11 都能跑网上能搜到的案例最多遇到问题最容易找到解法。别人都在踩新版本的坑时你已经把项目跑起来了。这就是稳赢策略。ORM 层面MyBatis-Plus 比原生 MyBatis 少写大量样板代码内置分页插件、条件构造器、代码生成器特别适合业务开发。很多同学想用 JPA但我个人不太建议在毕设里用它做复杂查询多表关联和动态条件拼接时不如 MyBatis 可控答辩时如果被问到“你这个多条件分页查询怎么实现的”用 MyBatis-Plus 的 LambdaQueryWrapper 讲起来也会清晰很多。前端选 Vue 3 是考虑到当前招聘市场的主流要求同时 Element Plus 组件库可以直接搭出一个好看的后台管理界面。如果你前端基础薄弱也可以选 Vue 2 Element UI资料更多但既然现在做毕设建议还是直接上 Vue 3代码里加一个组合式 API 的实践点答辩时反而是亮点。1.3 为什么不做微服务先想清楚边界有同学一上来就问我要不要用 Spring Cloud Alibaba、Nacos、Feign 那套。我的回答很统一除非老师明确要求否则不要做微服务。道理很简单餐饮管理系统的并发量级和业务复杂度用单体应用完全可以支撑硬拆微服务只会给自己增加服务注册、配置中心、分布式事务这类与业务本身无关的复杂度。毕设评分看的是你对业务的理解和工程化能力不是看服务拆了几个。但你可以把工程结构做得“模块化”一些在单体应用内部按业务边界分包common通用工具、config配置类、controller、service、mapper、entity、dto、vo。这样既能体现工程规范也为以后扩展留了余地。答辩时你可以说如果未来门店规模扩大可以将订单服务、用户服务、报表服务独立拆分部署当前单体架构满足了业务需求并简化了运维。这句话一出来老师就知道你想过架构演进的问题。2. 数据库设计与核心业务模型2.1 表结构设计从业务对象到数据模型数据库设计是这个项目的命脉设计不好后面写代码全是补丁。餐饮管理系统核心的表我建议至少包括这些用户表sys_user存储系统登录账号与员工信息关联角色表sys_role和菜单表sys_menu做 RBAC 权限控制菜品分类表category和菜品表dish维护菜单桌台表dining_table管理桌位状态订单表orders和订单明细表order_detail记录每一笔交易库存表stock管理食材数量再加一个系统日志表operation_log记录关键操作。订单表是最核心的一张表要特别花心思。我给出一个简化版结构供参考CREATE TABLE orders ( id bigint(20) NOT NULL AUTO_INCREMENT, order_no varchar(32) NOT NULL COMMENT 订单编号, table_id bigint(20) DEFAULT NULL COMMENT 桌台ID, user_id bigint(20) DEFAULT NULL COMMENT 操作员ID, customer_name varchar(64) DEFAULT NULL COMMENT 顾客姓名, total_amount decimal(10,2) NOT NULL COMMENT 总金额, discount_amount decimal(10,2) DEFAULT 0.00 COMMENT 优惠金额, pay_amount decimal(10,2) NOT NULL COMMENT 实付金额, status tinyint(4) NOT NULL COMMENT 状态1待支付 2制作中 3已出餐 4已完成 5已取消, pay_method tinyint(4) DEFAULT NULL COMMENT 支付方式1微信 2支付宝 3现金, remark varchar(255) DEFAULT NULL COMMENT 备注, create_time datetime NOT NULL COMMENT 下单时间, pay_time datetime DEFAULT NULL COMMENT 支付时间, finish_time datetime DEFAULT NULL COMMENT 完成时间, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no), KEY idx_status (status), KEY idx_create_time (create_time) ) ENGINEInnoDB AUTO_INCREMENT1 DEFAULT CHARSETutf8mb4 COMMENT订单表;金额字段我特别强调一下必须用 decimal(10,2)不要用 double 或 float。这不是矫情二进制浮点数在加减运算时会有精度损失订单金额这种敏感数据一旦出现 0.01 的误差财务对账的时候就麻烦了。BigDecimal 是 Java 端对应的类型MySQL 用 decimal两边配合起来才是正确姿势。订单号也不要让数据库自增 ID 直接暴露给用户一般用时间戳 随机数生成比如DateUtil.format(new Date(), yyyyMMddHHmmss)加上 4 位随机序列。这样既方便按单号查询也避免被竞争对手通过订单号推测日销量。2.2 状态流转设计订单和桌台的状态机餐饮系统的业务复杂度很大程度体现在状态流转上。订单状态我设计了五个待支付、制作中、已出餐、已完成、已取消。流转路径是顾客下单后先进入待支付支付成功后才通知后厨开始制作制作完成状态改成已出餐服务员上菜后顾客确认最后变成已完成。每一步操作都要记录操作人和操作时间这就是审计需求。这里有一个很容易被忽略的细节为什么要在“待支付”和“制作中”之间加一道闸因为如果不加客人下单不付款后厨已经开火做了最后客人跑单食材损失算谁的。设计成先支付后制作就避免了这种情况。当然现实中扫码点餐大多是小程序直接预付毕设里用“模拟支付”按钮代替真实支付这个流程逻辑必须完整。桌台状态我设计了四个空闲、已入座、已点餐、已结账待清理。一张桌台被客人扫了码状态就从空闲变成已入座下单成功变成已点餐结账完成变成已结账待清理服务员清理完手动置回空闲。桌台状态和订单状态要联动更新这里建议在同一个事务里操作避免状态不一致。2.3 库存扣减下单扣还是出餐扣库存设计看起来简单实则是个容易翻车的点。餐饮系统的库存管理有两种常见策略下单时扣减和出餐时扣减。下单扣减能防止超卖比如只剩一份食材两份订单同时下了最后一份只够做一桌但如果顾客取消订单或支付超时需要把库存加回来流程多一些。出餐扣减不会误扣但存在超卖风险高峰期可能出现菜单上显示有货后厨实际做不出来的情况。我的建议是毕设里做“下单扣减 取消回补”。核心逻辑是当你插入订单明细时同时执行库存表的扣减用UPDATE stock SET quantity quantity - #{num} WHERE dish_id #{dishId} AND quantity #{num}这样一条带条件的更新语句数据库层面就挡住了超卖。如果更新影响行数为 0说明库存不足下单接口直接抛出业务异常并回滚。这套方案实现简单也符合真实的餐饮业务直觉——客人点了这道菜食材就为他预留了。至于取消回补在取消订单的状态流转里把冻结库存加回去就行。3. 核心功能实现与开发实操3.1 项目初始化与目录结构规划使用 IDEA 创建 Spring Boot 项目时Spring Initializr 里勾选 Spring Web、MySQL Driver、Lombok 这几个依赖其他先不用勾。Maven 坐标里的 groupId 用 com.example 这种形式artifactId 用 restaurant-system。项目创建好后我习惯先把包目录搭好刚开始就规划清楚比后面再重构省事得多com.example.restaurant ├── common // 工具类、常量、统一响应类 ├── config // 配置类跨域、拦截器、MyBatis-Plus分页 ├── controller // 接口层 ├── service // 业务层接口实现 ├── mapper // 数据访问层 ├── entity // 数据库实体 ├── dto // 请求参数封装 └── vo // 响应数据封装common 包里最重要的是统一响应体。我定义一个ResultT类包含 code、message、data 三个字段所有接口都返回这个结构。这样做的好处是前后端联调有统一的约定前端 axios 响应拦截器里可以根据 code 判断成功还是失败不用每个接口单独写状态处理。代码大致长这样Data public class ResultT { private Integer code; private String message; private T data; public static T ResultT success(T data) { ResultT result new Result(); result.setCode(200); result.setMessage(操作成功); result.setData(data); return result; } public static T ResultT error(String message) { ResultT result new Result(); result.setCode(500); result.setMessage(message); return result; } }3.2 JWT 登录鉴权与拦截器配置登录功能是每个系统都有的基础模块很多同学直接用 HttpSession 存用户信息方便是方便但和现在主流的 “前后端分离 无状态鉴权” 模式不太匹配。毕设里建议用 JWT理由有两个一是贴合企业项目的主流做法二是答辩时这是个可以展开讲半分钟的亮点老师爱听。流程是这样的用户提交用户名密码后端校验通过后生成一个 JWT tokentoken 里可以放 userId、username、角色编码这几个字段设置过期时间比如 24 小时返回给前端。前端把 token 存在 localStorage 里每次请求放在请求头Authorization: Bearer token。后端写一个拦截器HandlerInterceptor对所有需要登录的接口做 token 校验解析 token 并从中取出用户信息放入 ThreadLocal业务代码里直接就能拿到当前用户上下文。拦截器里要排除登录接口、验证码接口、静态资源这些不需要鉴权的路径。这里有一个常见坑你不用 Spring Security 而是手写拦截器的话跨域预检请求OPTIONS也要放行否则前端每次请求都会被浏览器拦截联调时直接心态爆炸。我见过太多同学卡在这一步页面怎么都调不通接口最后发现是 OPTIONS 请求没过。3.3 点餐下单核心接口的实现细节点餐下单是餐饮系统最核心的接口它同时涉及多张表的写操作最适合展示一个开发者对事务和业务建模的理解。我直接贴一个简化版的核心代码框架Override Transactional(rollbackFor Exception.class) public OrderVO createOrder(OrderCreateDTO dto) { // 1. 校验桌台状态 DiningTable table diningTableMapper.selectById(dto.getTableId()); if (table null || !空闲.equals(table.getStatus())) { throw new BusinessException(桌台不可用); } // 2. 生成订单主表和明细 Orders order new Orders(); order.setOrderNo(generateOrderNo()); order.setTableId(dto.getTableId()); order.setStatus(1); // 待支付 order.setCreateTime(LocalDateTime.now()); ordersMapper.insert(order); BigDecimal total BigDecimal.ZERO; for (OrderItemDTO item : dto.getItems()) { Dish dish dishMapper.selectById(item.getDishId()); // 3. 扣减库存带条件更新 int rows stockMapper.deductStock(dish.getId(), item.getQuantity()); if (rows 0) { throw new BusinessException(菜品[ dish.getName() ]库存不足); } OrderDetail detail new OrderDetail(); detail.setOrderId(order.getId()); detail.setDishId(dish.getId()); detail.setDishName(dish.getName()); detail.setPrice(dish.getPrice()); detail.setQuantity(item.getQuantity()); orderDetailMapper.insert(detail); total total.add(dish.getPrice().multiply(BigDecimal.valueOf(item.getQuantity()))); } order.setTotalAmount(total); order.setPayAmount(total); ordersMapper.updateById(order); // 4. 更新桌台状态为已点餐 diningTableMapper.updateStatus(table.getId(), 已点餐); return orderVO; }看到这段代码有几个设计点我很想展开提醒一下第一Transactional必须指定rollbackFor Exception.class。Java 里RuntimeException和Error默认会触发回滚但受检异常不会如果业务层抛出的是 Exception 的子类而你没指定 rollbackFor事务不会回滚数据就出现一半写入一半没写入的脏状态。这是事务失效里最常见的坑。第二扣库存操作必须在事务内执行并且用带条件判断的更新语句。quantity #{num}这个条件不仅防止了超卖也是后续回滚的锚点。第三BigDecimal 之间不能用直接相加要用.add()方法初学的时候很容易在这上面写出编译错误。金额计算一定要保证是 BigDecimal 运算链全程不要出现 double。3.4 菜单角色权限RBAC 模型落地餐饮系统里老板、店长、收银员、后厨看到的界面和能操作的功能不一样这就是 RBAC基于角色的访问控制模型要解决的问题。数据层面三张表用户表和角色表多对多角色表和菜单表多对多中间各有一张关联表。后端做权限校验有两种做法。简单一点的是在拦截器里判断角色编码比如/admin/**开头的接口必须要有“管理员”角色才能访问。复杂一点的是基于注解 AOP 实现细粒度权限控制自定义一个RequirePermission(system:dish:add)注解AOP 切面里校验当前用户是否有这个菜单权限码。毕设建议用后者写起来不算复杂但体现的工程水准完全不一样。前端配合做动态路由用户登录后后端返回这个用户有权限的菜单列表前端根据菜单列表动态注册路由。这样不同角色登录后看到的侧边栏菜单项是不一样的演示效果非常直观。3.5 Redis 在系统里的两个应用场景Redis 这个组件加进项目里技术含量就上了一个台阶。餐饮管理系统里我建议用到两个场景一是登录验证码存储二是菜品分类缓存。验证码逻辑是生成一个 4 位随机数把验证码字符串存入 Rediskey 是用户唯一标识比如 UUID设置过期时间 120 秒同时把图片返回给前端。校验时从 Redis 取出并与用户输入比对用完立即删除。用 Redis 存验证码比存 Session 优雅多了因为 Session 可能跨服务无法共享虽然单体里不涉及但体现了分布式思维。菜品缓存是菜品在前端点餐页是高频访问的数据每次从数据库查会比较慢。我通常把菜品分类和菜品列表缓存到 Rediskey 设计成dish:category:{categoryId}设置缓存过期时间 30 分钟。当管理员修改菜品信息时删除对应缓存保证数据一致性。缓存雪崩和穿透的概念在答辩时也可以顺带提一句老师会认为你真的实践过缓存设计。4. 常见问题与排查技巧实录4.1 Spring Boot 版本陷阱JDK 与依赖的兼容性这个项目的用户里最让人头疼的问题就是版本不兼容。我在前面说过推荐 Spring Boot 2.7 JDK 8但还是有人已经装了 JDK 17 不想换。Spring Boot 2.7 是可以在 JDK 17 上运行的但你得注意两点一是 Lombok 的版本必须够新1.18.30 以上否则启动时直接报java.lang.IllegalAccessError二是 Maven 编译器插件要设置 Java 版本为 17。如果你非要尝试 Spring Boot 3.x心态上要做好准备javax.servlet、javax.annotation、javax.validation 这些包名在 Jakarta EE 9 之后全部变成了 jakarta 开头。你从网上复制来的旧代码如果写的是 javax编译直接报 “程序包不存在”。这本身不难改但如果项目里引了第三方依赖而它还没适配新版本那就是无底洞。我的核心建议还是那句话毕设求稳别追新。4.2 Maven 依赖下载卡死和 IDEA 配置问题开发环境最常见的两个报错一个是 IDEA 里创建项目后下载依赖一直卡在 downloading另一个是application.yml文件里写配置没有任何提示。第一个问题几乎都是 Maven 源的问题。国内直接连 Maven 中央仓库速度很慢需要把 Maven 的settings.xml里的 central 镜像改成阿里云镜像mirror idaliyunmaven/id mirrorOfcentral/mirrorOf name阿里云公共仓库/name urlhttps://maven.aliyun.com/repository/public/url /mirror注意改完镜像后要去 IDEA 的 Maven 设置里刷新一下有些版本需要重新导入项目才会重新下载。如果你经常遇到依赖下载不全的问题可以打开 Maven 面板点击“Reimport All Maven Projects”按钮强制刷新。第二个问题application.yml不提示最可能的原因是 IDEA 里没有引入 Spring Boot 的配置处理器依赖。在 pom.xml 里加上这个dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-configuration-processor/artifactId optionaltrue/optional /dependency然后重新构建项目。如果还是不提示检查一下是不是把文件放错目录了application.yml必须放在src/main/resources下不是src/main/java目录里。4.3 MyBatis-Plus 分页查不出数据你在联调分页接口时可能遇到这种情况单表查询正常一旦用了PageT分页查询出来的数据总是为空或者总条数不对。这个问题九成是没配置 MyBatis-Plus 的分页插件。MyBatis-Plus 3.5.x 里分页功能默认不是开启的必须手动把PaginationInnerInterceptor注入到 MyBatis 配置里Configuration public class MybatisPlusConfig { Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }不配置这个selectPage只会查出全部数据然后内存里分页这会导致两个问题一是数据量大时内存溢出风险二是分页 SQL 里的 LIMIT 语句根本没拼接返回的总条数其实是查到的全部数据条数。配置后控制台能看到分页 SQL 自动加了 COUNT 查询和 LIMIT 语句就说明生效了。4.4 前端跨域问题Nginx 代理和 CORS 双保险前后端分离项目联调时跨域是绕不开的坎。前端跑在 http://localhost:5173后端接口在 http://localhost:8080浏览器会拦截非同源的请求。这个问题我在项目里见过太多同学用“关闭浏览器安全策略”的方式来解决这只能应急不能作为最终方案。我建议后端配 CORS 前端配代理双保险。后端的 CORS 配置在一个配置类里实现Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); } }注意这里用allowedOriginPatterns(*)而不是allowedOrigins(*)因为当你设置了 allowCredentials(true) 时不允许使用通配符 * 作为来源。这是 Spring 5.3 之后的行为变化很多老教程没更新会导致配置了还报跨域错的诡异情况。前端的 Vite 配置里也可以加一个代理把/api开头的请求转发到后端地址export default defineConfig({ server: { proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } })这样开发时前端页面里请求路径写/api/xxx就不会跨域了。生产环境部署时用 Nginx 再做一次反向代理把/api转发到 Java 服务端口双保险。4.5 LocalDateTime 序列化与 JSON 格式问题后端接口返回的时间字段到前端变成了2024-03-20T10:30:00中间有个字母 T前端表格里显示很难看。这个问题出在 Jackson 默认的序列化方式上。两个解决办法一是在实体类的时间字段上统一加JsonFormat(pattern yyyy-MM-dd HH:mm:ss)二是全局配置一个 Jackson 的 ObjectMapper让它对 LocalDateTime 统一走格式化。我建议用第二种因为代码里时间字段太多了一个个加注解容易漏。写一个配置类Configuration public class JacksonConfig { Bean public Jackson2ObjectMapperBuilderCustomizer customizer() { return builder - builder.serializerByType(LocalDateTime.class, new LocalDateTimeSerializer(DateTimeFormatter.ofPattern(yyyy-MM-dd HH:mm:ss))) .deserializerByType(LocalDateTime.class, new LocalDateTimeDeserializer(DateTimeFormatter.ofPattern(yyyy-MM-dd HH:mm:ss))); } }另外一个相关的坑是MySQL 数据库连接的 URL 上要加上serverTimezoneAsia/Shanghai否则连接数据库会报时区错误。而且这只是连接层面的时区问题与 Jackson 序列化是两个层面的事都处理好了时间显示才完全正确。4.6 事务不生效的一堆隐蔽场景事务这块值得单独拎出来讲因为它的坑是隐蔽的报错也不会那么明显但数据就是不对。最常见的是同一个类里方法自调用public void doSomething() { // 事务生效 this.updateData(); } Transactional public void updateData() { // 这里的事务不会生效 }原因很简单Spring 的声明式事务是基于 AOP 动态代理实现的只有通过代理对象调用时才会触发事务逻辑而this.updateData()是直接调用当前对象的方法绕过了代理事务自然失效。解决办法是不要把Transactional加在同一个类的非事务方法调用的目标上要么把事务方法放到另一个 Service 类里注入调用要么在类内部注入自身代理或者用AopContext.currentProxy()。解法的核心就一句话事务方法必须通过 Spring 代理被调用才有效。还有一个场景是异常被 catch 掉导致事务失效。Transactional默认只对 RuntimeException 和 Error 回滚如果你在方法里把异常 catch 住了没有抛出事务当然不会回滚。更隐蔽的是你抛出了普通的 Exception受检异常但没指定rollbackFor Exception.class同样不会回滚。所以我前面说Transactional(rollbackFor Exception.class)要写全不是记性好都是被坑出来的。5. 部署上线与答辩亮点准备5.1 多环境配置与打包部署方案项目开发完接下来是部署。很多同学的毕设停留在“IDEA 里能跑就行”的程度这其实浪费了展示自己的机会。如果你能在答辩时用 Docker 把项目部署起来老师印象分会高很多。先把配置文件按环境拆开application-dev.yml是开发环境数据库指向本地application-prod.yml是生产环境数据库指向服务器application.yml只放公共配置通过spring.profiles.activeprod指定激活哪个环境。这样既规范又便于演示——答辩时可以现场切换配置说明你有环境隔离的意识。后端用 Docker 部署的话写一个 DockerfileFROM openjdk:8-jdk-alpine WORKDIR /app COPY target/restaurant-system-0.0.1-SNAPSHOT.jar app.jar EXPOSE 8080 ENTRYPOINT [java, -jar, app.jar, --spring.profiles.activeprod]这里有一个实际工作中很常见的坑如果你的打包环境是 JDK 17而 Docker 基础镜像用的是 JDK 8启动时会报UnsupportedClassVersionError因为编译出的 class 文件版本太高。解决办法是在 Maven 的pom.xml里指定java.version8/java.version让 Maven 编译时使用 release 8 的参数这样打出来的 jar 包在 JDK 8 环境里也能跑。如果你本机就是 JDK 8不会遇到这个问题但很多新版 IDEA 自带的 JDK 是 17 或 21这个坑就非常常见了。前端项目构建后是纯静态文件用 Nginx 部署最合适。build之后把dist目录里的内容放到 Nginx 的 html 目录下再配一个反向代理把/api转发到 Java 服务的 8080 端口然后把前端页面也监听 80 端口这样访问 http://服务器IP 就是完整的系统了。Nginx 配置大致这样server { listen 80; server_name localhost; location / { root /usr/share/nginx/html; index index.html; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://localhost:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }try_files $uri $uri/ /index.html;这一行是给前端路由用的写在最后防止刷新页面时 404。5.2 Docker Desktop 部署 Java 项目的注意事项如果你平时用 Docker DesktopWindows 或 Mac 环境部署 Spring Boot 项目还有几个易踩的坑要说一下。一是路径挂载问题。Windows 下 Docker Desktop 默认通过 WSL2 运行文件系统性能和路径映射行为和原生 Linux 不同。如果你用docker run -v挂载宿主机目录到容器注意宿主机路径写法要正确比如D:\restaurant\logs:/app/logs而且右键 Docker Desktop 的 Settings 里要确认 Shared Drives 或资源文件共享已经开启。二是端口冲突。如果你本机已经起了 MySQL 占用了 3306 端口容器里再起一个 MySQL 就会冲突。这个问题的最佳解法是容器化时把数据库服务单独定义用 docker-compose 编排。推荐用 docker-compose.yml 同时定义 mysql 和 app 两个服务这样 Java 服务和数据库都在容器网络里通过服务名互相访问避免端口冲突和 IP 写死的问题。5.3 答辩亮点把项目从“完成了”讲到“做得好”代码写完了部署上线了最后一步是把项目讲好。很多同学写的项目功能完整但答辩时只会照着 PPT 念需求列表老师问两句就卡住。我建议你在答辩前准备好这几个方向第一个是系统架构和思想层面的。你能不能说清楚为什么用单体架构而不用微服务为什么用 JWT 而不是 Session为什么数据库选 MySQL 而不是 Oracle这些问题没有标准答案但你要能给出“基于当前项目规模和时间成本的最优解”这样的回答逻辑。第二个是核心业务流程的深度理解。举个例子老师可能问“顾客下单后库存是怎么扣的如果客人在支付前取消了订单库存怎么处理”你如果能把“事务内扣库存 取消回补 防超卖条件更新”这套链路讲清楚就比单纯说“我用了事务”高一个层次。第三个是代码质量问题。比如“你用了Transactional那它底层实现原理是什么”这个问题能考察你对 Spring AOP 的理解。建议提前把 Spring 事务传播机制、AOP 动态代理JDK 动态代理和 CGLIB 的区别这两个知识点吃透。这两个是 Spring 面试的高频问题放到毕设答辩里同样是加分项。第四个是数据安全方面的思考。虽然毕设系统可能没有真实的黑客攻击但你可以主动讲讲密码存储用了 BCrypt 加密而不是明文登录接口做了验证码防暴力破解SQL 语句使用了预编译机制防注入JWT token 设置了过期时间等。这些点不大但每个都是一句话的亮点。最后提醒一下答辩的时候宁可在自己做过的地方讲细一点也不要泛泛而谈没做过的东西。比如你用了 Redis 做缓存就开始说 Redis 集群老师追问数据分片的细节你就答不上来了反而丢分。把做过的每一个点都吃透比吹一个没做过的分布式方案要强得多。这个项目做完你会发现它其实覆盖了 Java Web 开发里最常见的一整套套路前后端分离、RESTful 接口设计、数据库建模、权限认证、缓存使用、打包部署。把这套链路走通一遍比单纯刷一百道 SSM 面试题都有用。如果你正在为这个题目熬夜希望这篇文章能帮你少走点弯路把时间花在真正重要的功能实现上。
又到毕业设计选题季每年这个时候我都会收到一堆私信来问“Spring Boot 餐饮管理系统到底怎么做”。这个题目确实是计算机专业毕设里的常青树选它的人多坑也多——版本环境对不上、数据库设计一团乱、前后端联调跨域报错、答辩时被老师问住性能瓶颈。今天我就把这个题目从选题定位、技术选型、数据库设计、核心功能实现到部署上线和答辩准备一次性讲透结合我带过的项目经验和实际踩过的坑给准备做这个题目的同学一份可以直接抄作业的全流程参考。这篇内容适合三类人看一是正在为毕设选题发愁的计算机专业学生二是打算用 Spring Boot 练手做一个完整业务系统的初级开发者三是想了解餐饮管理系统后台到底怎么设计的产品和测试同学。我会尽量把每个环节为什么这么做讲清楚而不是只丢一堆代码和配置。1. 项目整体设计与技术选型思路1.1 为什么餐饮管理系统是毕设的稳妥之选选毕设题目核心就三条业务逻辑自己能讲明白、技术栈能覆盖主流知识点、工作量在三个月内能完成。餐饮管理系统恰好全中。它不像电商系统那样涉及复杂的支付分账和物流状态机也不像社交产品那样要处理高并发实时消息但它的业务闭环非常完整——从客户扫码点餐、后厨接单出餐、前台结账到菜品管理、库存预警、营业报表每个环节都有清晰的数据流转和状态变化。这种“麻雀虽小五脏俱全”的特性意味着你在答辩时能很自然地把整个业务流程串起来讲不用背稿子。更实际的一点是餐饮管理系统的需求可以自由裁剪。时间紧就做基础的点餐、订单、菜品模块时间充裕就再加桌台管理、会员营销、库存预警、数据可视化。它天然支持从低到高的复杂度扩展完全可以根据自己的进度动态调整范围。我做毕设指导这些年最容易翻车的反而是那些一开始就把题目定得很大的同学比如“基于微服务的电商平台”最后PPT里全是概念没有一个能跑通的完整链路。餐饮管理系统就很少出现这种情况。1.2 技术栈怎么选Spring Boot 2.7 MyBatis-Plus Vue 3技术栈的选择直接决定你后面三个月是高效开发还是天天配环境。这个项目的组合我比较推荐后端Spring Boot 2.7.x MyBatis-Plus 3.5.x MySQL 5.7/8.0 Redis前端Vue 3 Element Plus Axios Vite鉴权JWT 拦截器构建Maven部署Docker Nginx先说版本。我见过太多人一上来就装 Spring Boot 3.2然后发现网上教程全是 2.x 的写法javax 包改成 jakarta一堆老依赖废掉光改报错就花了一周。对于毕设来说Spring Boot 2.7 是最稳的版本本地环境用 JDK 8 或 JDK 11 都能跑网上能搜到的案例最多遇到问题最容易找到解法。别人都在踩新版本的坑时你已经把项目跑起来了。这就是稳赢策略。ORM 层面MyBatis-Plus 比原生 MyBatis 少写大量样板代码内置分页插件、条件构造器、代码生成器特别适合业务开发。很多同学想用 JPA但我个人不太建议在毕设里用它做复杂查询多表关联和动态条件拼接时不如 MyBatis 可控答辩时如果被问到“你这个多条件分页查询怎么实现的”用 MyBatis-Plus 的 LambdaQueryWrapper 讲起来也会清晰很多。前端选 Vue 3 是考虑到当前招聘市场的主流要求同时 Element Plus 组件库可以直接搭出一个好看的后台管理界面。如果你前端基础薄弱也可以选 Vue 2 Element UI资料更多但既然现在做毕设建议还是直接上 Vue 3代码里加一个组合式 API 的实践点答辩时反而是亮点。1.3 为什么不做微服务先想清楚边界有同学一上来就问我要不要用 Spring Cloud Alibaba、Nacos、Feign 那套。我的回答很统一除非老师明确要求否则不要做微服务。道理很简单餐饮管理系统的并发量级和业务复杂度用单体应用完全可以支撑硬拆微服务只会给自己增加服务注册、配置中心、分布式事务这类与业务本身无关的复杂度。毕设评分看的是你对业务的理解和工程化能力不是看服务拆了几个。但你可以把工程结构做得“模块化”一些在单体应用内部按业务边界分包common通用工具、config配置类、controller、service、mapper、entity、dto、vo。这样既能体现工程规范也为以后扩展留了余地。答辩时你可以说如果未来门店规模扩大可以将订单服务、用户服务、报表服务独立拆分部署当前单体架构满足了业务需求并简化了运维。这句话一出来老师就知道你想过架构演进的问题。2. 数据库设计与核心业务模型2.1 表结构设计从业务对象到数据模型数据库设计是这个项目的命脉设计不好后面写代码全是补丁。餐饮管理系统核心的表我建议至少包括这些用户表sys_user存储系统登录账号与员工信息关联角色表sys_role和菜单表sys_menu做 RBAC 权限控制菜品分类表category和菜品表dish维护菜单桌台表dining_table管理桌位状态订单表orders和订单明细表order_detail记录每一笔交易库存表stock管理食材数量再加一个系统日志表operation_log记录关键操作。订单表是最核心的一张表要特别花心思。我给出一个简化版结构供参考CREATE TABLE orders ( id bigint(20) NOT NULL AUTO_INCREMENT, order_no varchar(32) NOT NULL COMMENT 订单编号, table_id bigint(20) DEFAULT NULL COMMENT 桌台ID, user_id bigint(20) DEFAULT NULL COMMENT 操作员ID, customer_name varchar(64) DEFAULT NULL COMMENT 顾客姓名, total_amount decimal(10,2) NOT NULL COMMENT 总金额, discount_amount decimal(10,2) DEFAULT 0.00 COMMENT 优惠金额, pay_amount decimal(10,2) NOT NULL COMMENT 实付金额, status tinyint(4) NOT NULL COMMENT 状态1待支付 2制作中 3已出餐 4已完成 5已取消, pay_method tinyint(4) DEFAULT NULL COMMENT 支付方式1微信 2支付宝 3现金, remark varchar(255) DEFAULT NULL COMMENT 备注, create_time datetime NOT NULL COMMENT 下单时间, pay_time datetime DEFAULT NULL COMMENT 支付时间, finish_time datetime DEFAULT NULL COMMENT 完成时间, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no), KEY idx_status (status), KEY idx_create_time (create_time) ) ENGINEInnoDB AUTO_INCREMENT1 DEFAULT CHARSETutf8mb4 COMMENT订单表;金额字段我特别强调一下必须用 decimal(10,2)不要用 double 或 float。这不是矫情二进制浮点数在加减运算时会有精度损失订单金额这种敏感数据一旦出现 0.01 的误差财务对账的时候就麻烦了。BigDecimal 是 Java 端对应的类型MySQL 用 decimal两边配合起来才是正确姿势。订单号也不要让数据库自增 ID 直接暴露给用户一般用时间戳 随机数生成比如DateUtil.format(new Date(), yyyyMMddHHmmss)加上 4 位随机序列。这样既方便按单号查询也避免被竞争对手通过订单号推测日销量。2.2 状态流转设计订单和桌台的状态机餐饮系统的业务复杂度很大程度体现在状态流转上。订单状态我设计了五个待支付、制作中、已出餐、已完成、已取消。流转路径是顾客下单后先进入待支付支付成功后才通知后厨开始制作制作完成状态改成已出餐服务员上菜后顾客确认最后变成已完成。每一步操作都要记录操作人和操作时间这就是审计需求。这里有一个很容易被忽略的细节为什么要在“待支付”和“制作中”之间加一道闸因为如果不加客人下单不付款后厨已经开火做了最后客人跑单食材损失算谁的。设计成先支付后制作就避免了这种情况。当然现实中扫码点餐大多是小程序直接预付毕设里用“模拟支付”按钮代替真实支付这个流程逻辑必须完整。桌台状态我设计了四个空闲、已入座、已点餐、已结账待清理。一张桌台被客人扫了码状态就从空闲变成已入座下单成功变成已点餐结账完成变成已结账待清理服务员清理完手动置回空闲。桌台状态和订单状态要联动更新这里建议在同一个事务里操作避免状态不一致。2.3 库存扣减下单扣还是出餐扣库存设计看起来简单实则是个容易翻车的点。餐饮系统的库存管理有两种常见策略下单时扣减和出餐时扣减。下单扣减能防止超卖比如只剩一份食材两份订单同时下了最后一份只够做一桌但如果顾客取消订单或支付超时需要把库存加回来流程多一些。出餐扣减不会误扣但存在超卖风险高峰期可能出现菜单上显示有货后厨实际做不出来的情况。我的建议是毕设里做“下单扣减 取消回补”。核心逻辑是当你插入订单明细时同时执行库存表的扣减用UPDATE stock SET quantity quantity - #{num} WHERE dish_id #{dishId} AND quantity #{num}这样一条带条件的更新语句数据库层面就挡住了超卖。如果更新影响行数为 0说明库存不足下单接口直接抛出业务异常并回滚。这套方案实现简单也符合真实的餐饮业务直觉——客人点了这道菜食材就为他预留了。至于取消回补在取消订单的状态流转里把冻结库存加回去就行。3. 核心功能实现与开发实操3.1 项目初始化与目录结构规划使用 IDEA 创建 Spring Boot 项目时Spring Initializr 里勾选 Spring Web、MySQL Driver、Lombok 这几个依赖其他先不用勾。Maven 坐标里的 groupId 用 com.example 这种形式artifactId 用 restaurant-system。项目创建好后我习惯先把包目录搭好刚开始就规划清楚比后面再重构省事得多com.example.restaurant ├── common // 工具类、常量、统一响应类 ├── config // 配置类跨域、拦截器、MyBatis-Plus分页 ├── controller // 接口层 ├── service // 业务层接口实现 ├── mapper // 数据访问层 ├── entity // 数据库实体 ├── dto // 请求参数封装 └── vo // 响应数据封装common 包里最重要的是统一响应体。我定义一个ResultT类包含 code、message、data 三个字段所有接口都返回这个结构。这样做的好处是前后端联调有统一的约定前端 axios 响应拦截器里可以根据 code 判断成功还是失败不用每个接口单独写状态处理。代码大致长这样Data public class ResultT { private Integer code; private String message; private T data; public static T ResultT success(T data) { ResultT result new Result(); result.setCode(200); result.setMessage(操作成功); result.setData(data); return result; } public static T ResultT error(String message) { ResultT result new Result(); result.setCode(500); result.setMessage(message); return result; } }3.2 JWT 登录鉴权与拦截器配置登录功能是每个系统都有的基础模块很多同学直接用 HttpSession 存用户信息方便是方便但和现在主流的 “前后端分离 无状态鉴权” 模式不太匹配。毕设里建议用 JWT理由有两个一是贴合企业项目的主流做法二是答辩时这是个可以展开讲半分钟的亮点老师爱听。流程是这样的用户提交用户名密码后端校验通过后生成一个 JWT tokentoken 里可以放 userId、username、角色编码这几个字段设置过期时间比如 24 小时返回给前端。前端把 token 存在 localStorage 里每次请求放在请求头Authorization: Bearer token。后端写一个拦截器HandlerInterceptor对所有需要登录的接口做 token 校验解析 token 并从中取出用户信息放入 ThreadLocal业务代码里直接就能拿到当前用户上下文。拦截器里要排除登录接口、验证码接口、静态资源这些不需要鉴权的路径。这里有一个常见坑你不用 Spring Security 而是手写拦截器的话跨域预检请求OPTIONS也要放行否则前端每次请求都会被浏览器拦截联调时直接心态爆炸。我见过太多同学卡在这一步页面怎么都调不通接口最后发现是 OPTIONS 请求没过。3.3 点餐下单核心接口的实现细节点餐下单是餐饮系统最核心的接口它同时涉及多张表的写操作最适合展示一个开发者对事务和业务建模的理解。我直接贴一个简化版的核心代码框架Override Transactional(rollbackFor Exception.class) public OrderVO createOrder(OrderCreateDTO dto) { // 1. 校验桌台状态 DiningTable table diningTableMapper.selectById(dto.getTableId()); if (table null || !空闲.equals(table.getStatus())) { throw new BusinessException(桌台不可用); } // 2. 生成订单主表和明细 Orders order new Orders(); order.setOrderNo(generateOrderNo()); order.setTableId(dto.getTableId()); order.setStatus(1); // 待支付 order.setCreateTime(LocalDateTime.now()); ordersMapper.insert(order); BigDecimal total BigDecimal.ZERO; for (OrderItemDTO item : dto.getItems()) { Dish dish dishMapper.selectById(item.getDishId()); // 3. 扣减库存带条件更新 int rows stockMapper.deductStock(dish.getId(), item.getQuantity()); if (rows 0) { throw new BusinessException(菜品[ dish.getName() ]库存不足); } OrderDetail detail new OrderDetail(); detail.setOrderId(order.getId()); detail.setDishId(dish.getId()); detail.setDishName(dish.getName()); detail.setPrice(dish.getPrice()); detail.setQuantity(item.getQuantity()); orderDetailMapper.insert(detail); total total.add(dish.getPrice().multiply(BigDecimal.valueOf(item.getQuantity()))); } order.setTotalAmount(total); order.setPayAmount(total); ordersMapper.updateById(order); // 4. 更新桌台状态为已点餐 diningTableMapper.updateStatus(table.getId(), 已点餐); return orderVO; }看到这段代码有几个设计点我很想展开提醒一下第一Transactional必须指定rollbackFor Exception.class。Java 里RuntimeException和Error默认会触发回滚但受检异常不会如果业务层抛出的是 Exception 的子类而你没指定 rollbackFor事务不会回滚数据就出现一半写入一半没写入的脏状态。这是事务失效里最常见的坑。第二扣库存操作必须在事务内执行并且用带条件判断的更新语句。quantity #{num}这个条件不仅防止了超卖也是后续回滚的锚点。第三BigDecimal 之间不能用直接相加要用.add()方法初学的时候很容易在这上面写出编译错误。金额计算一定要保证是 BigDecimal 运算链全程不要出现 double。3.4 菜单角色权限RBAC 模型落地餐饮系统里老板、店长、收银员、后厨看到的界面和能操作的功能不一样这就是 RBAC基于角色的访问控制模型要解决的问题。数据层面三张表用户表和角色表多对多角色表和菜单表多对多中间各有一张关联表。后端做权限校验有两种做法。简单一点的是在拦截器里判断角色编码比如/admin/**开头的接口必须要有“管理员”角色才能访问。复杂一点的是基于注解 AOP 实现细粒度权限控制自定义一个RequirePermission(system:dish:add)注解AOP 切面里校验当前用户是否有这个菜单权限码。毕设建议用后者写起来不算复杂但体现的工程水准完全不一样。前端配合做动态路由用户登录后后端返回这个用户有权限的菜单列表前端根据菜单列表动态注册路由。这样不同角色登录后看到的侧边栏菜单项是不一样的演示效果非常直观。3.5 Redis 在系统里的两个应用场景Redis 这个组件加进项目里技术含量就上了一个台阶。餐饮管理系统里我建议用到两个场景一是登录验证码存储二是菜品分类缓存。验证码逻辑是生成一个 4 位随机数把验证码字符串存入 Rediskey 是用户唯一标识比如 UUID设置过期时间 120 秒同时把图片返回给前端。校验时从 Redis 取出并与用户输入比对用完立即删除。用 Redis 存验证码比存 Session 优雅多了因为 Session 可能跨服务无法共享虽然单体里不涉及但体现了分布式思维。菜品缓存是菜品在前端点餐页是高频访问的数据每次从数据库查会比较慢。我通常把菜品分类和菜品列表缓存到 Rediskey 设计成dish:category:{categoryId}设置缓存过期时间 30 分钟。当管理员修改菜品信息时删除对应缓存保证数据一致性。缓存雪崩和穿透的概念在答辩时也可以顺带提一句老师会认为你真的实践过缓存设计。4. 常见问题与排查技巧实录4.1 Spring Boot 版本陷阱JDK 与依赖的兼容性这个项目的用户里最让人头疼的问题就是版本不兼容。我在前面说过推荐 Spring Boot 2.7 JDK 8但还是有人已经装了 JDK 17 不想换。Spring Boot 2.7 是可以在 JDK 17 上运行的但你得注意两点一是 Lombok 的版本必须够新1.18.30 以上否则启动时直接报java.lang.IllegalAccessError二是 Maven 编译器插件要设置 Java 版本为 17。如果你非要尝试 Spring Boot 3.x心态上要做好准备javax.servlet、javax.annotation、javax.validation 这些包名在 Jakarta EE 9 之后全部变成了 jakarta 开头。你从网上复制来的旧代码如果写的是 javax编译直接报 “程序包不存在”。这本身不难改但如果项目里引了第三方依赖而它还没适配新版本那就是无底洞。我的核心建议还是那句话毕设求稳别追新。4.2 Maven 依赖下载卡死和 IDEA 配置问题开发环境最常见的两个报错一个是 IDEA 里创建项目后下载依赖一直卡在 downloading另一个是application.yml文件里写配置没有任何提示。第一个问题几乎都是 Maven 源的问题。国内直接连 Maven 中央仓库速度很慢需要把 Maven 的settings.xml里的 central 镜像改成阿里云镜像mirror idaliyunmaven/id mirrorOfcentral/mirrorOf name阿里云公共仓库/name urlhttps://maven.aliyun.com/repository/public/url /mirror注意改完镜像后要去 IDEA 的 Maven 设置里刷新一下有些版本需要重新导入项目才会重新下载。如果你经常遇到依赖下载不全的问题可以打开 Maven 面板点击“Reimport All Maven Projects”按钮强制刷新。第二个问题application.yml不提示最可能的原因是 IDEA 里没有引入 Spring Boot 的配置处理器依赖。在 pom.xml 里加上这个dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-configuration-processor/artifactId optionaltrue/optional /dependency然后重新构建项目。如果还是不提示检查一下是不是把文件放错目录了application.yml必须放在src/main/resources下不是src/main/java目录里。4.3 MyBatis-Plus 分页查不出数据你在联调分页接口时可能遇到这种情况单表查询正常一旦用了PageT分页查询出来的数据总是为空或者总条数不对。这个问题九成是没配置 MyBatis-Plus 的分页插件。MyBatis-Plus 3.5.x 里分页功能默认不是开启的必须手动把PaginationInnerInterceptor注入到 MyBatis 配置里Configuration public class MybatisPlusConfig { Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }不配置这个selectPage只会查出全部数据然后内存里分页这会导致两个问题一是数据量大时内存溢出风险二是分页 SQL 里的 LIMIT 语句根本没拼接返回的总条数其实是查到的全部数据条数。配置后控制台能看到分页 SQL 自动加了 COUNT 查询和 LIMIT 语句就说明生效了。4.4 前端跨域问题Nginx 代理和 CORS 双保险前后端分离项目联调时跨域是绕不开的坎。前端跑在 http://localhost:5173后端接口在 http://localhost:8080浏览器会拦截非同源的请求。这个问题我在项目里见过太多同学用“关闭浏览器安全策略”的方式来解决这只能应急不能作为最终方案。我建议后端配 CORS 前端配代理双保险。后端的 CORS 配置在一个配置类里实现Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); } }注意这里用allowedOriginPatterns(*)而不是allowedOrigins(*)因为当你设置了 allowCredentials(true) 时不允许使用通配符 * 作为来源。这是 Spring 5.3 之后的行为变化很多老教程没更新会导致配置了还报跨域错的诡异情况。前端的 Vite 配置里也可以加一个代理把/api开头的请求转发到后端地址export default defineConfig({ server: { proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } })这样开发时前端页面里请求路径写/api/xxx就不会跨域了。生产环境部署时用 Nginx 再做一次反向代理把/api转发到 Java 服务端口双保险。4.5 LocalDateTime 序列化与 JSON 格式问题后端接口返回的时间字段到前端变成了2024-03-20T10:30:00中间有个字母 T前端表格里显示很难看。这个问题出在 Jackson 默认的序列化方式上。两个解决办法一是在实体类的时间字段上统一加JsonFormat(pattern yyyy-MM-dd HH:mm:ss)二是全局配置一个 Jackson 的 ObjectMapper让它对 LocalDateTime 统一走格式化。我建议用第二种因为代码里时间字段太多了一个个加注解容易漏。写一个配置类Configuration public class JacksonConfig { Bean public Jackson2ObjectMapperBuilderCustomizer customizer() { return builder - builder.serializerByType(LocalDateTime.class, new LocalDateTimeSerializer(DateTimeFormatter.ofPattern(yyyy-MM-dd HH:mm:ss))) .deserializerByType(LocalDateTime.class, new LocalDateTimeDeserializer(DateTimeFormatter.ofPattern(yyyy-MM-dd HH:mm:ss))); } }另外一个相关的坑是MySQL 数据库连接的 URL 上要加上serverTimezoneAsia/Shanghai否则连接数据库会报时区错误。而且这只是连接层面的时区问题与 Jackson 序列化是两个层面的事都处理好了时间显示才完全正确。4.6 事务不生效的一堆隐蔽场景事务这块值得单独拎出来讲因为它的坑是隐蔽的报错也不会那么明显但数据就是不对。最常见的是同一个类里方法自调用public void doSomething() { // 事务生效 this.updateData(); } Transactional public void updateData() { // 这里的事务不会生效 }原因很简单Spring 的声明式事务是基于 AOP 动态代理实现的只有通过代理对象调用时才会触发事务逻辑而this.updateData()是直接调用当前对象的方法绕过了代理事务自然失效。解决办法是不要把Transactional加在同一个类的非事务方法调用的目标上要么把事务方法放到另一个 Service 类里注入调用要么在类内部注入自身代理或者用AopContext.currentProxy()。解法的核心就一句话事务方法必须通过 Spring 代理被调用才有效。还有一个场景是异常被 catch 掉导致事务失效。Transactional默认只对 RuntimeException 和 Error 回滚如果你在方法里把异常 catch 住了没有抛出事务当然不会回滚。更隐蔽的是你抛出了普通的 Exception受检异常但没指定rollbackFor Exception.class同样不会回滚。所以我前面说Transactional(rollbackFor Exception.class)要写全不是记性好都是被坑出来的。5. 部署上线与答辩亮点准备5.1 多环境配置与打包部署方案项目开发完接下来是部署。很多同学的毕设停留在“IDEA 里能跑就行”的程度这其实浪费了展示自己的机会。如果你能在答辩时用 Docker 把项目部署起来老师印象分会高很多。先把配置文件按环境拆开application-dev.yml是开发环境数据库指向本地application-prod.yml是生产环境数据库指向服务器application.yml只放公共配置通过spring.profiles.activeprod指定激活哪个环境。这样既规范又便于演示——答辩时可以现场切换配置说明你有环境隔离的意识。后端用 Docker 部署的话写一个 DockerfileFROM openjdk:8-jdk-alpine WORKDIR /app COPY target/restaurant-system-0.0.1-SNAPSHOT.jar app.jar EXPOSE 8080 ENTRYPOINT [java, -jar, app.jar, --spring.profiles.activeprod]这里有一个实际工作中很常见的坑如果你的打包环境是 JDK 17而 Docker 基础镜像用的是 JDK 8启动时会报UnsupportedClassVersionError因为编译出的 class 文件版本太高。解决办法是在 Maven 的pom.xml里指定java.version8/java.version让 Maven 编译时使用 release 8 的参数这样打出来的 jar 包在 JDK 8 环境里也能跑。如果你本机就是 JDK 8不会遇到这个问题但很多新版 IDEA 自带的 JDK 是 17 或 21这个坑就非常常见了。前端项目构建后是纯静态文件用 Nginx 部署最合适。build之后把dist目录里的内容放到 Nginx 的 html 目录下再配一个反向代理把/api转发到 Java 服务的 8080 端口然后把前端页面也监听 80 端口这样访问 http://服务器IP 就是完整的系统了。Nginx 配置大致这样server { listen 80; server_name localhost; location / { root /usr/share/nginx/html; index index.html; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://localhost:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }try_files $uri $uri/ /index.html;这一行是给前端路由用的写在最后防止刷新页面时 404。5.2 Docker Desktop 部署 Java 项目的注意事项如果你平时用 Docker DesktopWindows 或 Mac 环境部署 Spring Boot 项目还有几个易踩的坑要说一下。一是路径挂载问题。Windows 下 Docker Desktop 默认通过 WSL2 运行文件系统性能和路径映射行为和原生 Linux 不同。如果你用docker run -v挂载宿主机目录到容器注意宿主机路径写法要正确比如D:\restaurant\logs:/app/logs而且右键 Docker Desktop 的 Settings 里要确认 Shared Drives 或资源文件共享已经开启。二是端口冲突。如果你本机已经起了 MySQL 占用了 3306 端口容器里再起一个 MySQL 就会冲突。这个问题的最佳解法是容器化时把数据库服务单独定义用 docker-compose 编排。推荐用 docker-compose.yml 同时定义 mysql 和 app 两个服务这样 Java 服务和数据库都在容器网络里通过服务名互相访问避免端口冲突和 IP 写死的问题。5.3 答辩亮点把项目从“完成了”讲到“做得好”代码写完了部署上线了最后一步是把项目讲好。很多同学写的项目功能完整但答辩时只会照着 PPT 念需求列表老师问两句就卡住。我建议你在答辩前准备好这几个方向第一个是系统架构和思想层面的。你能不能说清楚为什么用单体架构而不用微服务为什么用 JWT 而不是 Session为什么数据库选 MySQL 而不是 Oracle这些问题没有标准答案但你要能给出“基于当前项目规模和时间成本的最优解”这样的回答逻辑。第二个是核心业务流程的深度理解。举个例子老师可能问“顾客下单后库存是怎么扣的如果客人在支付前取消了订单库存怎么处理”你如果能把“事务内扣库存 取消回补 防超卖条件更新”这套链路讲清楚就比单纯说“我用了事务”高一个层次。第三个是代码质量问题。比如“你用了Transactional那它底层实现原理是什么”这个问题能考察你对 Spring AOP 的理解。建议提前把 Spring 事务传播机制、AOP 动态代理JDK 动态代理和 CGLIB 的区别这两个知识点吃透。这两个是 Spring 面试的高频问题放到毕设答辩里同样是加分项。第四个是数据安全方面的思考。虽然毕设系统可能没有真实的黑客攻击但你可以主动讲讲密码存储用了 BCrypt 加密而不是明文登录接口做了验证码防暴力破解SQL 语句使用了预编译机制防注入JWT token 设置了过期时间等。这些点不大但每个都是一句话的亮点。最后提醒一下答辩的时候宁可在自己做过的地方讲细一点也不要泛泛而谈没做过的东西。比如你用了 Redis 做缓存就开始说 Redis 集群老师追问数据分片的细节你就答不上来了反而丢分。把做过的每一个点都吃透比吹一个没做过的分布式方案要强得多。这个项目做完你会发现它其实覆盖了 Java Web 开发里最常见的一整套套路前后端分离、RESTful 接口设计、数据库建模、权限认证、缓存使用、打包部署。把这套链路走通一遍比单纯刷一百道 SSM 面试题都有用。如果你正在为这个题目熬夜希望这篇文章能帮你少走点弯路把时间花在真正重要的功能实现上。
