毕业设计实战：基于 Spring Boot 的校园食堂订餐系统架构设计与避坑指南

---

背景痛点：学生项目最容易踩的三颗雷

做校园食堂订餐系统，说简单也简单，说难是真难。很多同学把“下单”理解成“往订单表插一条记录”，结果一上并发测试，现场翻车：

1. 无事务边界——下单接口里先插订单、再扣库存、再更新用户余额，三步放一块却不用@Transactional，中途一出异常，订单回滚了，库存却扣了，食堂阿姨直接报警。
2. 未处理超卖——并发 10 个请求同时买最后 1 份黄焖鸡，库存字段version都没加，结果卖出 10 份，老板当场社死。
3. 接口无鉴权——谁都能拿 Postman 调/order/delete把别人订单删了，毕业答辩现场表演删库跑路。

雷点先抛出来，下面给一套能直接跑、能抗并发的实战方案。

技术选型：为什么不是 SSM 而是 Spring Boot + MyBatis-Plus + Redis + Vue

1. Spring Boot：脚手架一键成型，内嵌 Tomcat，告别“配 XML 配到毕业”。
2. MyBatis-Plus：封装常用 CRUD，Lambda 写法写 SQL 像写 Java，毕业设计时间紧，不写重复 XML 就能早下班。
3. Redis：内存挡一层，令牌限流、库存缓存、分布式锁一把梭，答辩老师问“并发怎么保证”时直接把SETNX甩他脸上。
4. Vue + Element-Plus：前后端分离，食堂大屏、手机 H5、管理员后台三端复用，模板市场组件多，UI 不花冤枉钱。

对比 SSM（Spring + SpringMVC + MyBatis）：

• 配置量翻倍，光spring-mvc.xml就能写一页 A4；
• 没有自动装配，写单元测得先 new 十来个 Bean；
• 打包得额外装 Maven Tomcat 插件，CI 流程复杂。

结论：毕业设计周期 3 个月以内，直接上 Spring Boot 全家桶，把时间留给业务而不是配环境。

核心实现细节：订单、库存、权限三板斧

1. 订单幂等性设计

对外暴露的订单创建接口必须支持幂等，否则用户狂点“提交”就生成 5 条待支付订单，体验炸裂。

实现思路：前端生成orderToken（UUID），放进订单表唯一索引字段。后端利用数据库唯一键冲突抛DuplicateKeyException，捕获后直接返回“订单已提交”，既保证幂等又省一次 SELECT。

2. 菜品库存原子扣减

超卖根源是“读-改-写”非原子。把库存提前缓存到 Redis，key 为stock:item:{dishId}，值是剩余份数。

扣减流程：

1. 使用RedisTemplate.execute()执行 Lua 脚本，保证get→decr≥0→set原子；
2. Lua 返回剩余库存< 0时回滚，前端提示“已售罄”；
3. 订单支付成功后，异步消息（Spring Event 或 RocketMQ）再真正写 DB 库存，Redis 与 MySQL 最终一致。

3. 用户角色权限模型

校园场景三类角色：学生（下单）、食堂管理员（维护菜品）、系统管理员（看报表）。采用 RBAC0 模型：

• 用户表user
• 角色表role
• 权限表permission
• 用户角色中间表、角色权限中间表

JWT 里只存userId与roleCodes，网关层做拦截，方法级再用@PreAuthorize("hasRole('STUDENT')")精准控制。毕业答辩常被问“为什么不用 Session”，答：“ Stateless 易水平扩展，食堂高峰期加机器不踩坑”。

关键代码片段：Clean Code 示范

Service 层——带事务的下单方法

@Override @Transactional(rollbackFor = Exception.class) public Long createOrder(Long userId, OrderCreateDTO dto, String orderToken) { // 1. 幂等校验 Order exist = orderMapper.selectOne(new LambdaQueryWrapper<Order>() .eq(Order::getOrderToken, orderToken)); if (exist != null) { return exist.getId(); // 已提交过，直接返回 } // 2. Redis 原子扣库存 String key = "stock:item:" + dto.getDishId(); Long left = redisTemplate.execute( stockLuaScript, Collections.singletonList(key), dto.getQuantity().toString()); if (left < 0) { throw new BizException("库存不足"); } // 3. 组装订单 Order order = new Order(); order.setUserId(userId); order.setAmount(dto.getAmount()); order.setOrderToken(orderToken); orderMapper.insert(order); // 4. 写订单明细 OrderItem item = new OrderItem(); item.setOrderId(order.getId()); item.setDishId(dto.getDishId()); item.setQuantity(dto.getQuantity()); orderItemMapper.insert(item); return order.getId(); }

Redis 分布式锁工具类

@Component public class RedisLock { @Autowired private StringRedisTemplate template; /** * 非阻塞获取锁 * @param key 锁key * @param value 唯一value，用于释放锁时校验 * @param seconds 过期秒数 * @return 是否拿到锁 */ public boolean tryLock(String key, String value, long seconds) { Boolean flag = template.opsForValue() .setIfAbsent(key, value, seconds, TimeUnit.SECONDS); return Boolean.TRUE.equals(flag); } public void unlock(String key, String value) { // 使用 Lua 保证 GET+DEL 原子 String lua = "if redis.call('get', KEYS[1]) == ARGV[1] then " + "return redis.call('del', KEYS[1]) else return 0 end"; template.execute(new DefaultRedisScript<>(lua, Long.class), Collections.singletonList(key), value); } }

代码要点：

• 魔法值提常量、分支提前 return，减少嵌套；
• 事务与锁粒度只包住“库存”与“订单”临界区，尽量短；
• 日志打orderToken与userId，方便链路追踪。

性能与安全考量

1. 冷启动延迟
   Spring Boot 3.x + Java 17 启动时间约 1.2s，毕业设计答辩机器老旧，可打开-XX:TieredStopAtLevel=1做分层编译，首次请求从 3s 降到 1s 内，老师刷新页面不尴尬。

2. SQL 注入
   MyBatis-Plus 条件构造器已预编译，但手写 XML 时务必#{}占位，别图省事${}拼接；另外开启全局过滤器blockAttackSqlFilter，把or 1=1直接拦掉。

3. Token 刷新机制
   双 Token（Access + Refresh）模型，Access 过期 15min，Refresh 7 天。前端拦截 401，自动用 Refresh 换新的 Access，用户重新点菜不跳登录。Refresh Token 存 Redis 并设过期，可一键吊销。

生产环境避坑指南

1. 数据库连接池
   学生机 2C4G，Hikari 默认maximumPoolSize=10足够；云服务器 1C2G 就别开 10，压测时 CPU 飙满，老师以为你 DDoS 自己。先select 1做健康检查，防止防火墙把空闲连接踢掉导致“MySQL has gone away”。

2. 跨域配置
   前端 Vue 跑localhost:5173，后端localhost:8080，不只是一句allowedOrigins("*")就完事。Spring Security 6 以后得：

   CorsConfigurationSource corsConfigurationSource() { CorsConfiguration config = new CorsConfiguration(); config.setAllowedOriginPatterns(List.of("*")); config.addAllowedHeader("*"); config.addAllowedMethod("*"); config.setAllowCredentials(true); return exchange -> config; }

   否则带 Cookie 的 JWT 死活写不进去，联调现场抓耳挠腮。

3. 日志级别
   线上root=INFO即可，把 SQL 打印关掉，磁盘爆满会把老师的服务器搞挂，直接判不及格。

留给你的思考题：如何扩展为多食堂多档口？

当前工程只有一张dish表，字段window存“A 食堂一楼”。如果以后要接校内 8 个食堂、每个食堂 20 个档口，表结构怎么拆？库存是按“档口维度”还是“食堂维度”聚合？Redis key 如何设计避免热 key？分布式事务要不要上 Seata？——别急着给答案，先动手把现有代码拉下来，跑通压测，再重构一遍，你会更深刻理解“高内聚、低耦合”到底长什么样。

毕业设计不是终点，把食堂系统真正跑起来，让室友天天在上面点鸡腿，才是对代码最好的尊重。祝你答辩顺利，代码无 bug，提前干饭！

---