每年毕业季我都会收到一堆学弟学妹的消息问毕设到底选什么题目。Java方向的题库里翻来覆去就那么几个名字“网上订餐系统”算是出现频率最高的之一。很多人嫌它老套、没新意但我得说句公道话这恰恰是Java Web方向最适合做毕设的题目之一。原因很简单你打开美团点一单外卖整个链路里涉及的场景几乎覆盖了业务系统开发的核心知识点。用户、菜品、购物车、订单、支付状态、后台接单这是一条完整的业务闭环不是那种CRUD凑出来的空壳项目。这篇内容我按自己当年带项目、自己也亲手写过一遍的经验把从选题、数据库设计、核心逻辑到避坑、答辩的全过程拆给你看。不是让你照抄而是让你知道每一步为什么要这么做。1. 为什么我劝你选“网上订餐系统”当毕设题目1.1 表面老套实则五脏俱全先说说选题逻辑。毕设题目最怕两种一种是纯管理系统用户管理、菜单管理、增删改查做完你会发现除了CRUD啥也没学到答辩时老师问一句“你觉得难点在哪”你就卡住了另一种是过度炫技分布式、微服务、高并发一套吹下来代码自己都跑不通答辩翻车更惨。网上订餐系统正好卡在中间。它有一个完整的商业场景用户浏览菜品、加入购物车、确认订单、模拟支付、商家接单、订单状态流转、历史订单查询再加上后台的菜品分类管理、库存管理、订单处理。业务深度足够你展示事务控制、状态管理、关联查询、权限控制这些真实开发里天天用的东西但又不会难到超出本科毕设的承受范围。更关键的是这个系统天然分两个端用户端和商家管理端。这意味着你必须考虑角色权限、数据隔离、页面跳转逻辑而不是把所有功能堆在一个界面上。很多毕设项目死于“功能列表很长但系统架构是平的”订餐系统因为业务约束天然逼你分层。1.2 一眼就能让答辩老师看懂的“闭环业务”答辩现场和写代码是两回事。你花了大半年做的推荐算法可能老师五分钟内看不出含金量但订餐系统从“用户下单”到“商家接单”再到“订单完成”演示路径非常直观。老师能顺着你的操作一步步看懂每个功能在干什么这本身就是巨大的加分项。我见过太多人在答辩时讲得云里雾里核心原因不是他做得少而是业务链条断开。订餐系统天然有叙事逻辑打开首页看到菜品分类 → 选菜加购 → 填写地址提交订单 → 模拟支付 → 从商家后台看到新订单 → 接单并更新状态 → 用户端订单状态跟着变。这一段走完整个系统的价值就立住了。所以选题这事别光看题目新不新要看它能不能承载你要展示的技术点以及你答辩时能不能把它讲成一个完整的故事。2. 技术选型毕设不追新重点是你讲得清2.1 主流方案的横向对比Java方向的Web项目这些年演进过几代我把常见的组合拉出来对比一下技术组合优点缺点适合人群JSP Servlet JDBC学完JavaWeb课就会代码透明开发效率低页面和逻辑耦合严重动手能力弱求稳SSMSpring SpringMVC MyBatis经典企业级组合资料多配置繁琐光XML就好几个想体现传统功底Spring Boot MyBatis/MyBatis-Plus起步快约定大于配置主流封装较好需要理解自动配置绝大多数人Spring Boot JPA/Hibernate对象关系映射省事SQL控制力弱进阶排查困难熟悉ORM的同学我的建议很直接如果你没有特别强的理由就用 Spring Boot MyBatis-Plus MySQL。理由有三个第一Spring Boot 是目前Java后端的事实标准这套选型拿到面试里也是加分项不浪费第二MyBatis-Plus 把单表CRUD封装得极简你省下来的时间可以去打磨核心业务代码而不是在Mapper XML里写一堆重复SQL第三网上资料最多、报错最好查。毕设期间你会遇到无数奇奇怪怪的bug一个成熟的生态能节省大量时间。2.2 我的最终选型与项目分层我推荐的组合是这样后端框架Spring Boot 2.7.x稳定资料多别追求最新版本ORMMyBatis-Plus 3.5.x数据库MySQL 8.0前端方案后台管理用Thymeleaf Bootstrap用户端可以接一个简单的Vue页面或者干脆也用服务端渲染登录认证JWT 或 Session二者选一后面细讲构建工具Maven项目结构上一定要分层清晰。Controller层只负责接收参数和返回结果不写业务逻辑Service层放核心业务规则Mapper层只做数据访问。这个分层不仅是代码规范问题更是你的设计文档和答辩PPT里要写的东西。一个我常用也推荐给学生的包结构是这样的com.ordering ├── controller // 控制层 │ ├── admin // 后台管理端接口 │ └── user // 用户端接口 ├── service // 业务层 │ ├── impl ├── mapper // 数据访问层 ├── entity // 数据库实体 ├── dto // 数据传输对象 ├── vo // 视图对象 ├── config // 配置类 ├── common // 通用工具与返回结果封装 └── interceptor // 拦截器登录校验等不要小看这个结构。答辩老师翻你代码的时候第一眼就看包结构。一个按业务功能堆砌的目录和一个按职责分层的目录专业感完全不一样。2.3 前端方案怎么定很多同学纠结要不要搞前后端分离。我的看法是想清楚你的核心目标。如果你的重点是想展示Spring Boot的后端能力那用Thymeleaf做服务端渲染完全够用还把JSP时代的页面开发经验延续下来调试简单、部署也简单一个jar包就能跑。如果你本身前端基础不错或者想在毕设里多展示一项技能那用一个简单的Vue3 Element Plus做后台页面也没问题但注意要控制复杂度别让前端调试消耗太多时间。我个人带项目的经验是时间紧就用服务端渲染时间宽裕再考虑前后端分离。毕设的评分核心在后端设计和业务完整性CSS写得再漂亮也只是锦上添花。3. 数据库设计订单系统的根基全在表结构里3.1 核心表清单与字段设计订餐系统的数据模型不管你怎么演化核心逃不开这几张表用户表、菜品分类表、菜品表、购物车表、订单表、订单明细表、收货地址表。我一个个说。用户表user核心字段字段类型说明idbigint主键自增usernamevarchar登录名唯一passwordvarchar加密存储别存明文phonevarchar手机号avatarvarchar头像URLstatustinyint1启用 0禁用create_timedatetime注册时间这里我要专门说一下密码存储。很多毕设代码里密码都是明文存的答辩时老师如果问你“密码安全怎么考虑”会很尴尬。用MD5加盐或者BCrypt都行。Spring Security里自带的BCryptPasswordEncoder可以直接用代码量不大但安全这块的评分点就拿到了。菜品表dish要特别注意的字段是category_id所属分类、price价格、stock库存、status是否上架、image图片路径。库存字段很多人会漏掉但要实现下单扣库存的并发控制这个字段是基础。订单表orders是整张数据库设计的核心字段要设计周全字段类型说明idbigint订单号展示用order_novarchar业务订单号用时间戳随机数生成user_idbigint下单用户total_amountdecimal(10,2)总金额pay_amountdecimal(10,2)实付金额pay_typetinyint支付方式 1微信 2支付宝 3余额statustinyint订单状态address_idbigint收货地址IDremarkvarchar备注create_timedatetime下单时间pay_timedatetime支付时间订单明细表order_item是为了多对多关系必须拆的一张表。一个订单可以包含多个菜品所以一个菜品也可以出现在多个订单里按数据库三范式必须拆出明细表。字段包括order_id订单ID、dish_id菜品ID、dish_name下单时的菜品名、dish_image、price下单时价格、quantity数量、subtotal小计金额。这里有个容易被忽略的细节明细表里保存dish_name和price。为什么不能下单后通过dish_id去关联菜品表取名字和价格因为菜品可能改价、可能删除但历史订单必须保留下单那一刻的快照。这是电商系统中“快照”思想的入门级体现答辩论这题非常加分。3.2 订单状态设计用整数还是字符串订单状态是整个系统里最需要想清楚的设计。很多同学会直接用字符串“未支付”“已支付”“待发货”但状态用整数枚举更规范理由有三存储空间小查询效率高状态流转可以在代码里用枚举或常量统一管理避免“已支付”和“支付完成”这种同义不同字的脏数据扩展方便新增状态不用改已有数据。我设计的订单状态如下状态值含义说明0待支付已下单但未支付1已支付/待接单支付成功等待商家处理2商家已接单/制作中商家确认接单3配送中骑手取餐配送4已完成用户确认收货或自动完成5已取消支付前取消或商家拒单6已退款支付后退款状态值不要用连续的带有业务含义的数字留出扩展空间。比如状态从0跳到1、跳到2中间万一以后要加“支付中”状态不能把已有值改掉所以设计时就要留余量。代码里建议用常量类统一声明比如 OrderStatus.java里面定义 public static final int UNPAID 0; 这样业务代码里写状态判断时直观可读也不会出现莫名其妙的魔法数字。3.3 索引与关联关系的取舍数据库性能这块毕设项目数据量小索引的压力体现不出来但设计习惯要有。订单表里的 user_id、create_time 要建索引因为你查“我的订单”和“按时间筛选”都用得到订单明细表的 order_id 必须建索引因为每次查询订单详情都要关联明细表菜品表的 category_id 建索引因为按分类展示菜品是高频操作。另外注意一点不要在关联查询里滥用外键。很多教材喜欢讲外键约束但真实开发里大表往往不建物理外键而是通过应用层保证数据一致性。毕设里用不用外键都行但我建议你在文档里说明“我没用物理外键是为了后续分库分表做铺垫”这句话能把普通设计和有思考的设计区分开。4. 核心业务逻辑实现下单这件事远没有想象中简单4.1 从加购物车到提交订单的完整链路很多人的订餐系统做到最后所有功能都是“把表单数据insert进数据库”这是最要命的。一旦做到下单这个环节业务逻辑就复杂起来了校验菜品是否在售 → 校验库存是否充足 → 计算总金额 → 生成订单号 → 保存订单主表 → 保存订单明细 → 扣减库存 → 清空购物车。这中间任何一步失败都不能留下半截数据。先看购物车加购逻辑相对简单用户登录状态下往购物车表插入或更新记录。判断标准是同一个用户、同一个菜品如果已经在购物车里就加数量否则新增一条。这个判断放在Service层做不要裸写SQL在Controller里。再看提交订单这是整套系统的核心方法。我写一个简化的下单流程伪代码Transactional(rollbackFor Exception.class) public OrderVO createOrder(CreateOrderDTO dto) { // 1. 校验收货地址归属 Address address addressService.getById(dto.getAddressId()); if (address null || !address.getUserId().equals(currentUserId())) { throw new BusinessException(收货地址不合法); } // 2. 查询购物车中选中的菜品列表 ListCartItem cartItems cartMapper.selectCheckedItems(userId); if (cartItems null || cartItems.isEmpty()) { throw new BusinessException(购物车为空); } // 3. 遍历校验菜品状态与库存计算总金额 BigDecimal totalAmount BigDecimal.ZERO; ListOrderItem orderItems new ArrayList(); for (CartItem item : cartItems) { Dish dish dishMapper.selectById(item.getDishId()); if (dish null || dish.getStatus() ! 1) { throw new BusinessException(菜品已下架: item.getDishName()); } if (dish.getStock() item.getQuantity()) { throw new BusinessException(菜品库存不足: dish.getName()); } BigDecimal subtotal dish.getPrice().multiply(BigDecimal.valueOf(item.getQuantity())); totalAmount totalAmount.add(subtotal); OrderItem orderItem new OrderItem(); orderItem.setDishId(dish.getId()); orderItem.setDishName(dish.getName()); orderItem.setPrice(dish.getPrice()); orderItem.setQuantity(item.getQuantity()); orderItem.setSubtotal(subtotal); orderItems.add(orderItem); } // 4. 生成订单号 String orderNo generateOrderNo(); // 5. 保存订单主表 Orders order new Orders(); order.setOrderNo(orderNo); order.setUserId(userId); order.setTotalAmount(totalAmount); order.setStatus(OrderStatus.UNPAID); order.setCreateTime(new Date()); orderMapper.insert(order); // 6. 批量保存订单明细 for (OrderItem item : orderItems) { item.setOrderId(order.getId()); } orderItemMapper.insertBatch(orderItems); // 7. 扣减库存 for (CartItem item : cartItems) { dishMapper.deductStock(item.getDishId(), item.getQuantity()); } // 8. 清空已选购物车 cartMapper.deleteCheckedItems(userId); return buildOrderVO(order, orderItems); }这是整个系统的“心脏”方法。有几点要细说事务非常重要。方法上加 Transactional(rollbackFor Exception.class)保证第5步到第8步是一个原子操作。如果扣库存时发现失败抛了异常前面插入的订单和明细全部回滚数据库不会留下脏数据。这里的 rollbackFor 必须写默认情况下 RuntimeException 才触发回滚比如抓了Exception没往外抛事务就不生效了。金额计算用BigDecimal。第3步里我用BigDecimal而不是double原因是double在二进制存储中本身就存在精度误差0.1 0.2 这种看似简单的小数运算在价格累计时会产生毛刺。BigDecimal虽然性能差点但精度可靠。这个问题后面的章节还会专门讲。校验的顺序有讲究。先校验地址再校验菜品最后才生成订单号、插入数据。原则是能把无效请求拦截在数据库写入之前就拦截掉避免浪费事务资源和主键ID。4.2 事务控制为什么下单必须加Transactional我可以负责任地说很多同学的毕设代码里事务是缺失的。不加事务的下单方法是什么后果假如库存扣减在步骤7但订单插入在步骤5。如果库存扣了之后、清购物车之前抛了一个异常这个订单就变成了“订单还在库存却没了”的状态。用户实际上没下单成功但套餐里的菜被扣掉了。大白话解释事务它保证了一组数据库操作要么全部成功、要么全部失败。就像转账扣款和收款必须同时成功不能出现钱扣了对方没收到的情况。下单也是一样创建订单和扣减库存是一个整体不能拆开。另外一个高频坑是事务不生效。常见原因有两个。第一方法被同一个类内部调用比如 Controller 调本类的另一个方法而那个内部方法加了 Transactional因为Spring的事务是通过代理实现的内部调用不走代理注解就失效了。正确做法是事务方法放到不同类里由外部通过代理调用。第二异常被吞掉。你在Service里 try-catch 把 Exception 吃掉了Spring感知不到异常自然不会回滚。要么把事务方法里的异常重新抛出要么在 catch 块里手动 TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()。我建议第一种抛出异常由全局异常处理器统一处理代码更干净。4.3 支付模块没有真实支付接口怎么设计很多同学前期最焦虑的就是支付模块——我没有商户号接不了微信支付和支付宝怎么办答案很简单模拟支付。但模拟支付不要做成“点击一下就变成已支付”这种毫无过程的伪逻辑。我建议你这样设计提交订单后生成一笔支付记录payment表状态为待支付用户点击“去支付”时跳到一个模拟收银台页面上面显示订单号、金额、支付方式选择点击“确认支付”后后台做三件事校验订单当前状态必须是待支付更新订单状态为已支付/待接单记录支付时间记录支付流水。这个流程看起来只是多了一步但你在答辩时就能说清楚真实支付系统的核心设计在于“订单状态”与“支付结果通知”的一致性保障我把它抽象成了本地事务处理。将来对接微信支付时只需要把“确认支付”这一步替换成调用微信下单接口在回调里完成同样的状态更新逻辑。如果能再进一步在支付前后分别校验订单状态是否允许本次操作并在写支付流水时检查该订单是否已有成功支付记录就可以顺带说一句幂等设计。这已经是网上订餐系统里能拿得出手的纵深了。5. 开发中真正踩过的坑并发、精度、状态机5.1 库存超卖并发下最常见的翻车现场单机单用户测试一切正常为什么需要担心库存超卖因为真实场景里一个系统要同时服务很多用户。假设一个菜只剩1份两个用户同时下单理论上只能成功一个但如果代码是“先查库存、判断够不够、再扣库存”这种三步逻辑并发情况下就会出问题用户A查库存剩余1够用户B查库存剩余1够用户A扣库存变成0用户B扣库存变成-1。这就是超卖。而毕设答辩里这个问题几乎是必问题。你要么没做并发控制老师问住了要么做了哪怕只是最简单的乐观锁都能让老师看到你的工程意识。我用的方案很简单不引入Redis分布式锁就在SQL层面解决UPDATE dish SET stock stock - #{quantity} WHERE id #{id} AND stock #{quantity}这行SQL返回影响行数如果为0说明库存不够本次扣减失败抛异常触发事务回滚。原理是通过数据库的行锁保证并发安全的扣减。关键点在于 WHERE 条件里带上了 stock #{quantity}在更新前就校验了库存足够而不是先查询再更新。这是我整个项目里最值得在答辩时讲的一个点从“查询再更新”到“带条件更新”仅仅是设计思路的转变但效果完全不同。5.2 金额计算double的锅BigDecimal来背价格字段在数据库里我用 decimal(10,2)在Java实体里我用 BigDecimal这两个决定如果在整个项目里贯彻下去金额精度问题就不会踩雷。怕就怕有的人数据库用decimal、Java里用double算总价的时候直接 double total price * quantity那算到小数位就可能出现 0.10.20.30000000000000004 这种离谱结果。有同学可能觉得差一点点没所谓但在实际业务里金额对不上账是大事故金额计算也要求绝对精确。简单的规则数据库金额字段用decimal不用float/doubleJava实体用BigDecimal不用double前端传金额参数用字符串或分为单位避免浮点数序列化误差BigDecimal构造时用字符串构造new BigDecimal(19.9)不要new BigDecimal(19.9)。最后一条很多人不知道。new BigDecimal(19.9) 的底层其实是把浮点数的二进制近似值原样带进来结果还是带了一堆小数而传字符串“19.9”才是精确的。这属于那种“看API文档根本注意不到、踩过一次再也不忘”的坑。5.3 状态流转混乱给订单状态写一张“许可表”项目做到后面订单状态一多就非常容易出现“状态随便跳”的bug。比如待支付的订单直接变成已完成或者已取消的订单又被接单。问题根源在于每个操作都在无脑更新状态没有任何约束。我的做法是定义一张状态流转许可表每个状态允许向哪些状态流转写清楚后再实现通用的状态更新方法public class OrderStatusTransfer { private static final MapInteger, SetInteger ALLOWED_TRANSFER new HashMap(); static { // 待支付可取消可支付 ALLOWED_TRANSFER.put(OrderStatus.UNPAID, new HashSet(Arrays.asList(OrderStatus.CANCELLED, OrderStatus.PAID))); // 已支付可取消退款可接单 ALLOWED_TRANSFER.put(OrderStatus.PAID, new HashSet(Arrays.asList(OrderStatus.REFUNDED, OrderStatus.ACCEPTED))); // 已接单可开始配送 ALLOWED_TRANSFER.put(OrderStatus.ACCEPTED, new HashSet(Arrays.asList(OrderStatus.DELIVERING))); // 配送中可完成 ALLOWED_TRANSFER.put(OrderStatus.DELIVERING, new HashSet(Arrays.asList(OrderStatus.COMPLETED))); // 已完成、已取消、已退款终态不允许再变更 } public static void checkTransfer(int from, int to) { SetInteger allowed ALLOWED_TRANSFER.get(from); if (allowed null || !allowed.contains(to)) { throw new BusinessException(非法的订单状态流转); } } }然后所有更新订单状态的地方都先调用 checkTransfer(当前状态, 目标状态)再执行update。这个设计在答辩时非常好讲如何用预定义的状态机约束业务流转防止非法操作。5.4 登录状态Session还是JWT用户登录后怎么维持状态是个必写的模块也是个答辩必问题。两种方案各有优势。Session方案是传统JavaWeb的思路登录成功后把用户信息放Session里后续请求通过拦截器从Session取用户ID。实现简单配合Spring Boot的拦截器很容易做但问题在分布式环境下Session不共享需要Redis做Session共享。JWT方案是无状态认证登录成功后签发一个Token前端存起来后续请求放在请求头里后端解析Token获取用户信息。优点是不依赖服务端存储、天然支持水平扩展但缺陷是Token一旦签发到期前无法主动失效需要额外维护黑名单。毕设项目怎么选如果做的是单体应用我觉得Session就够代码量最少、逻辑最好讲。但如果你不想在答辩时被追问“Session在分布式环境下怎么办”直接用JWT把Redis加进来做登录黑名单和验证码这个架构就立起来了。我用JWT时的具体做法Component public class JwtUtil { Value(${jwt.secret}) private String secret; Value(${jwt.expire}) private Long expire; // 单位秒 public String createToken(Long userId, String username) { return Jwts.builder() .setSubject(username) .claim(userId, userId) .setIssuedAt(new Date()) .setExpiration(new Date(System.currentTimeMillis() expire * 1000)) .signWith(SignatureAlgorithm.HS256, secret) .compact(); } public Claims parseToken(String token) { return Jwts.parser().setSigningKey(secret) .parseClaimsJws(token).getBody(); } }再配一个拦截器在进入Controller之前校验Token把解析出来的用户ID放入ThreadLocal或请求属性中。代码量不大但整个系统的“当前用户从哪来”这个问题就被统一解决了。6. 答辩演示与常见追问把做过的东西讲成自己的6.1 演示流程怎么编排最加分产品做完了答辩演示的顺序很讲究。不要一上来就展示后台管理的增删改查那是最不吸引人的部分。按业务故事来走第一步演示用户注册登录强调密码不是明文存储的用的是加密算法。 第二步打开首页展示菜品按分类展示的效果随便点开一个菜品强调库存字段和上下架状态。 第三步加购物车结算填写地址提交订单重点展示下单成功后订单金额计算正确、进入待支付状态。 第四步模拟支付看到订单状态变成已支付强调支付流程和状态一致性设计。 第五步切换到商家后台看到新订单接单、配送每一步都切回用户端刷新展示订单状态同步变化。 第六步最后展示历史订单列表和订单详情说明明细表里的菜品名称是快照数据。这套流程走下来等于把整个系统的数据库设计、业务逻辑、状态机控制全部串联了一遍而且每一步都有对应的页面反馈。演示过程中顺便说一句“这个操作涉及到事务回滚”“这个状态变化走的是状态机校验”含金量就出来了。6.2 高频追问与应对思路我把自己当评委列出几个必问的问题你提前把答案准备扎实为什么选择Spring Boot而不是SSH或者Spring Cloud答Spring Boot简化了配置适合快速构建单体应用本次毕设重点在业务完整性单体架构足够承载Spring Cloud的微服务治理在这个场景里属于过度设计但我了解其设计思想后续扩展时可以按业务拆分成服务。你的系统如何防止库存超卖答在扣减库存的SQL中用 stock #{quantity} 作为条件通过数据库行锁保证并发安全。如果未来并发量更高可以引入Redislua脚本实现原子扣减或使用消息队列削峰。订单和支付如何保证数据一致答在单体应用中订单创建、支付状态更新都在一个数据库事务里完成保证强一致如果拆分为微服务则采用本地消息表或事务消息最终一致性。你怎么理解数据库事务的隔离级别答我用的是MySQL默认的REPEATABLE READ在这个业务场景里因为关键操作都通过SQL原子更新和行锁保证安全隔离级别满足需求。更深一层可以说明MVCC机制的原理。这些问题其实没有标准答案老师考察的是你有没有自己的思考逻辑。哪怕答得不完美只要你能围绕“选型理由、对比方案、改进方向”说清楚就比背下来的八股文强一百倍。6.3 还能往哪个方向扩展如果时间充裕想给项目加亮点我给你三个性价比最高的方向一是加Redis缓存。首页菜品列表、菜品分类这些读多写少的数据缓存到Redis里减少数据库压力。这一个点就能在架构图上多画一个组件。二是加WebSocket。商家接单后用户端页面实时弹出“商家已接单”的提醒不需要用户手动刷新。WebSocket的握手、Session管理也是Java面试里偏加分的内容。三是加Excel导出。后台加一个订单报表导出功能用EasyExcel把订单列表导出成Excel文件。这个功能实用性极强操作也不复杂但展示效果非常直观。以上每个扩展都能在答辩时单独讲三分钟而且都是“看得见的实际功能”不是纸上谈兵。最后说点实在的。我在带毕设的过程中发现一个规律最后得高分的往往不是代码炫技最多的而是逻辑最完整、讲得最清楚的。网上订餐系统这个题目功能边界清晰技术栈成熟你只要把数据库设计做扎实、核心下单逻辑的事务和并发控制做对、订单状态机管理好再把答辩演示串成一条业务故事线就已经超过一大批人了。别想着什么都做把核心链路打磨到位比堆功能清单有用得多。
每年毕业季我都会收到一堆学弟学妹的消息问毕设到底选什么题目。Java方向的题库里翻来覆去就那么几个名字“网上订餐系统”算是出现频率最高的之一。很多人嫌它老套、没新意但我得说句公道话这恰恰是Java Web方向最适合做毕设的题目之一。原因很简单你打开美团点一单外卖整个链路里涉及的场景几乎覆盖了业务系统开发的核心知识点。用户、菜品、购物车、订单、支付状态、后台接单这是一条完整的业务闭环不是那种CRUD凑出来的空壳项目。这篇内容我按自己当年带项目、自己也亲手写过一遍的经验把从选题、数据库设计、核心逻辑到避坑、答辩的全过程拆给你看。不是让你照抄而是让你知道每一步为什么要这么做。1. 为什么我劝你选“网上订餐系统”当毕设题目1.1 表面老套实则五脏俱全先说说选题逻辑。毕设题目最怕两种一种是纯管理系统用户管理、菜单管理、增删改查做完你会发现除了CRUD啥也没学到答辩时老师问一句“你觉得难点在哪”你就卡住了另一种是过度炫技分布式、微服务、高并发一套吹下来代码自己都跑不通答辩翻车更惨。网上订餐系统正好卡在中间。它有一个完整的商业场景用户浏览菜品、加入购物车、确认订单、模拟支付、商家接单、订单状态流转、历史订单查询再加上后台的菜品分类管理、库存管理、订单处理。业务深度足够你展示事务控制、状态管理、关联查询、权限控制这些真实开发里天天用的东西但又不会难到超出本科毕设的承受范围。更关键的是这个系统天然分两个端用户端和商家管理端。这意味着你必须考虑角色权限、数据隔离、页面跳转逻辑而不是把所有功能堆在一个界面上。很多毕设项目死于“功能列表很长但系统架构是平的”订餐系统因为业务约束天然逼你分层。1.2 一眼就能让答辩老师看懂的“闭环业务”答辩现场和写代码是两回事。你花了大半年做的推荐算法可能老师五分钟内看不出含金量但订餐系统从“用户下单”到“商家接单”再到“订单完成”演示路径非常直观。老师能顺着你的操作一步步看懂每个功能在干什么这本身就是巨大的加分项。我见过太多人在答辩时讲得云里雾里核心原因不是他做得少而是业务链条断开。订餐系统天然有叙事逻辑打开首页看到菜品分类 → 选菜加购 → 填写地址提交订单 → 模拟支付 → 从商家后台看到新订单 → 接单并更新状态 → 用户端订单状态跟着变。这一段走完整个系统的价值就立住了。所以选题这事别光看题目新不新要看它能不能承载你要展示的技术点以及你答辩时能不能把它讲成一个完整的故事。2. 技术选型毕设不追新重点是你讲得清2.1 主流方案的横向对比Java方向的Web项目这些年演进过几代我把常见的组合拉出来对比一下技术组合优点缺点适合人群JSP Servlet JDBC学完JavaWeb课就会代码透明开发效率低页面和逻辑耦合严重动手能力弱求稳SSMSpring SpringMVC MyBatis经典企业级组合资料多配置繁琐光XML就好几个想体现传统功底Spring Boot MyBatis/MyBatis-Plus起步快约定大于配置主流封装较好需要理解自动配置绝大多数人Spring Boot JPA/Hibernate对象关系映射省事SQL控制力弱进阶排查困难熟悉ORM的同学我的建议很直接如果你没有特别强的理由就用 Spring Boot MyBatis-Plus MySQL。理由有三个第一Spring Boot 是目前Java后端的事实标准这套选型拿到面试里也是加分项不浪费第二MyBatis-Plus 把单表CRUD封装得极简你省下来的时间可以去打磨核心业务代码而不是在Mapper XML里写一堆重复SQL第三网上资料最多、报错最好查。毕设期间你会遇到无数奇奇怪怪的bug一个成熟的生态能节省大量时间。2.2 我的最终选型与项目分层我推荐的组合是这样后端框架Spring Boot 2.7.x稳定资料多别追求最新版本ORMMyBatis-Plus 3.5.x数据库MySQL 8.0前端方案后台管理用Thymeleaf Bootstrap用户端可以接一个简单的Vue页面或者干脆也用服务端渲染登录认证JWT 或 Session二者选一后面细讲构建工具Maven项目结构上一定要分层清晰。Controller层只负责接收参数和返回结果不写业务逻辑Service层放核心业务规则Mapper层只做数据访问。这个分层不仅是代码规范问题更是你的设计文档和答辩PPT里要写的东西。一个我常用也推荐给学生的包结构是这样的com.ordering ├── controller // 控制层 │ ├── admin // 后台管理端接口 │ └── user // 用户端接口 ├── service // 业务层 │ ├── impl ├── mapper // 数据访问层 ├── entity // 数据库实体 ├── dto // 数据传输对象 ├── vo // 视图对象 ├── config // 配置类 ├── common // 通用工具与返回结果封装 └── interceptor // 拦截器登录校验等不要小看这个结构。答辩老师翻你代码的时候第一眼就看包结构。一个按业务功能堆砌的目录和一个按职责分层的目录专业感完全不一样。2.3 前端方案怎么定很多同学纠结要不要搞前后端分离。我的看法是想清楚你的核心目标。如果你的重点是想展示Spring Boot的后端能力那用Thymeleaf做服务端渲染完全够用还把JSP时代的页面开发经验延续下来调试简单、部署也简单一个jar包就能跑。如果你本身前端基础不错或者想在毕设里多展示一项技能那用一个简单的Vue3 Element Plus做后台页面也没问题但注意要控制复杂度别让前端调试消耗太多时间。我个人带项目的经验是时间紧就用服务端渲染时间宽裕再考虑前后端分离。毕设的评分核心在后端设计和业务完整性CSS写得再漂亮也只是锦上添花。3. 数据库设计订单系统的根基全在表结构里3.1 核心表清单与字段设计订餐系统的数据模型不管你怎么演化核心逃不开这几张表用户表、菜品分类表、菜品表、购物车表、订单表、订单明细表、收货地址表。我一个个说。用户表user核心字段字段类型说明idbigint主键自增usernamevarchar登录名唯一passwordvarchar加密存储别存明文phonevarchar手机号avatarvarchar头像URLstatustinyint1启用 0禁用create_timedatetime注册时间这里我要专门说一下密码存储。很多毕设代码里密码都是明文存的答辩时老师如果问你“密码安全怎么考虑”会很尴尬。用MD5加盐或者BCrypt都行。Spring Security里自带的BCryptPasswordEncoder可以直接用代码量不大但安全这块的评分点就拿到了。菜品表dish要特别注意的字段是category_id所属分类、price价格、stock库存、status是否上架、image图片路径。库存字段很多人会漏掉但要实现下单扣库存的并发控制这个字段是基础。订单表orders是整张数据库设计的核心字段要设计周全字段类型说明idbigint订单号展示用order_novarchar业务订单号用时间戳随机数生成user_idbigint下单用户total_amountdecimal(10,2)总金额pay_amountdecimal(10,2)实付金额pay_typetinyint支付方式 1微信 2支付宝 3余额statustinyint订单状态address_idbigint收货地址IDremarkvarchar备注create_timedatetime下单时间pay_timedatetime支付时间订单明细表order_item是为了多对多关系必须拆的一张表。一个订单可以包含多个菜品所以一个菜品也可以出现在多个订单里按数据库三范式必须拆出明细表。字段包括order_id订单ID、dish_id菜品ID、dish_name下单时的菜品名、dish_image、price下单时价格、quantity数量、subtotal小计金额。这里有个容易被忽略的细节明细表里保存dish_name和price。为什么不能下单后通过dish_id去关联菜品表取名字和价格因为菜品可能改价、可能删除但历史订单必须保留下单那一刻的快照。这是电商系统中“快照”思想的入门级体现答辩论这题非常加分。3.2 订单状态设计用整数还是字符串订单状态是整个系统里最需要想清楚的设计。很多同学会直接用字符串“未支付”“已支付”“待发货”但状态用整数枚举更规范理由有三存储空间小查询效率高状态流转可以在代码里用枚举或常量统一管理避免“已支付”和“支付完成”这种同义不同字的脏数据扩展方便新增状态不用改已有数据。我设计的订单状态如下状态值含义说明0待支付已下单但未支付1已支付/待接单支付成功等待商家处理2商家已接单/制作中商家确认接单3配送中骑手取餐配送4已完成用户确认收货或自动完成5已取消支付前取消或商家拒单6已退款支付后退款状态值不要用连续的带有业务含义的数字留出扩展空间。比如状态从0跳到1、跳到2中间万一以后要加“支付中”状态不能把已有值改掉所以设计时就要留余量。代码里建议用常量类统一声明比如 OrderStatus.java里面定义 public static final int UNPAID 0; 这样业务代码里写状态判断时直观可读也不会出现莫名其妙的魔法数字。3.3 索引与关联关系的取舍数据库性能这块毕设项目数据量小索引的压力体现不出来但设计习惯要有。订单表里的 user_id、create_time 要建索引因为你查“我的订单”和“按时间筛选”都用得到订单明细表的 order_id 必须建索引因为每次查询订单详情都要关联明细表菜品表的 category_id 建索引因为按分类展示菜品是高频操作。另外注意一点不要在关联查询里滥用外键。很多教材喜欢讲外键约束但真实开发里大表往往不建物理外键而是通过应用层保证数据一致性。毕设里用不用外键都行但我建议你在文档里说明“我没用物理外键是为了后续分库分表做铺垫”这句话能把普通设计和有思考的设计区分开。4. 核心业务逻辑实现下单这件事远没有想象中简单4.1 从加购物车到提交订单的完整链路很多人的订餐系统做到最后所有功能都是“把表单数据insert进数据库”这是最要命的。一旦做到下单这个环节业务逻辑就复杂起来了校验菜品是否在售 → 校验库存是否充足 → 计算总金额 → 生成订单号 → 保存订单主表 → 保存订单明细 → 扣减库存 → 清空购物车。这中间任何一步失败都不能留下半截数据。先看购物车加购逻辑相对简单用户登录状态下往购物车表插入或更新记录。判断标准是同一个用户、同一个菜品如果已经在购物车里就加数量否则新增一条。这个判断放在Service层做不要裸写SQL在Controller里。再看提交订单这是整套系统的核心方法。我写一个简化的下单流程伪代码Transactional(rollbackFor Exception.class) public OrderVO createOrder(CreateOrderDTO dto) { // 1. 校验收货地址归属 Address address addressService.getById(dto.getAddressId()); if (address null || !address.getUserId().equals(currentUserId())) { throw new BusinessException(收货地址不合法); } // 2. 查询购物车中选中的菜品列表 ListCartItem cartItems cartMapper.selectCheckedItems(userId); if (cartItems null || cartItems.isEmpty()) { throw new BusinessException(购物车为空); } // 3. 遍历校验菜品状态与库存计算总金额 BigDecimal totalAmount BigDecimal.ZERO; ListOrderItem orderItems new ArrayList(); for (CartItem item : cartItems) { Dish dish dishMapper.selectById(item.getDishId()); if (dish null || dish.getStatus() ! 1) { throw new BusinessException(菜品已下架: item.getDishName()); } if (dish.getStock() item.getQuantity()) { throw new BusinessException(菜品库存不足: dish.getName()); } BigDecimal subtotal dish.getPrice().multiply(BigDecimal.valueOf(item.getQuantity())); totalAmount totalAmount.add(subtotal); OrderItem orderItem new OrderItem(); orderItem.setDishId(dish.getId()); orderItem.setDishName(dish.getName()); orderItem.setPrice(dish.getPrice()); orderItem.setQuantity(item.getQuantity()); orderItem.setSubtotal(subtotal); orderItems.add(orderItem); } // 4. 生成订单号 String orderNo generateOrderNo(); // 5. 保存订单主表 Orders order new Orders(); order.setOrderNo(orderNo); order.setUserId(userId); order.setTotalAmount(totalAmount); order.setStatus(OrderStatus.UNPAID); order.setCreateTime(new Date()); orderMapper.insert(order); // 6. 批量保存订单明细 for (OrderItem item : orderItems) { item.setOrderId(order.getId()); } orderItemMapper.insertBatch(orderItems); // 7. 扣减库存 for (CartItem item : cartItems) { dishMapper.deductStock(item.getDishId(), item.getQuantity()); } // 8. 清空已选购物车 cartMapper.deleteCheckedItems(userId); return buildOrderVO(order, orderItems); }这是整个系统的“心脏”方法。有几点要细说事务非常重要。方法上加 Transactional(rollbackFor Exception.class)保证第5步到第8步是一个原子操作。如果扣库存时发现失败抛了异常前面插入的订单和明细全部回滚数据库不会留下脏数据。这里的 rollbackFor 必须写默认情况下 RuntimeException 才触发回滚比如抓了Exception没往外抛事务就不生效了。金额计算用BigDecimal。第3步里我用BigDecimal而不是double原因是double在二进制存储中本身就存在精度误差0.1 0.2 这种看似简单的小数运算在价格累计时会产生毛刺。BigDecimal虽然性能差点但精度可靠。这个问题后面的章节还会专门讲。校验的顺序有讲究。先校验地址再校验菜品最后才生成订单号、插入数据。原则是能把无效请求拦截在数据库写入之前就拦截掉避免浪费事务资源和主键ID。4.2 事务控制为什么下单必须加Transactional我可以负责任地说很多同学的毕设代码里事务是缺失的。不加事务的下单方法是什么后果假如库存扣减在步骤7但订单插入在步骤5。如果库存扣了之后、清购物车之前抛了一个异常这个订单就变成了“订单还在库存却没了”的状态。用户实际上没下单成功但套餐里的菜被扣掉了。大白话解释事务它保证了一组数据库操作要么全部成功、要么全部失败。就像转账扣款和收款必须同时成功不能出现钱扣了对方没收到的情况。下单也是一样创建订单和扣减库存是一个整体不能拆开。另外一个高频坑是事务不生效。常见原因有两个。第一方法被同一个类内部调用比如 Controller 调本类的另一个方法而那个内部方法加了 Transactional因为Spring的事务是通过代理实现的内部调用不走代理注解就失效了。正确做法是事务方法放到不同类里由外部通过代理调用。第二异常被吞掉。你在Service里 try-catch 把 Exception 吃掉了Spring感知不到异常自然不会回滚。要么把事务方法里的异常重新抛出要么在 catch 块里手动 TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()。我建议第一种抛出异常由全局异常处理器统一处理代码更干净。4.3 支付模块没有真实支付接口怎么设计很多同学前期最焦虑的就是支付模块——我没有商户号接不了微信支付和支付宝怎么办答案很简单模拟支付。但模拟支付不要做成“点击一下就变成已支付”这种毫无过程的伪逻辑。我建议你这样设计提交订单后生成一笔支付记录payment表状态为待支付用户点击“去支付”时跳到一个模拟收银台页面上面显示订单号、金额、支付方式选择点击“确认支付”后后台做三件事校验订单当前状态必须是待支付更新订单状态为已支付/待接单记录支付时间记录支付流水。这个流程看起来只是多了一步但你在答辩时就能说清楚真实支付系统的核心设计在于“订单状态”与“支付结果通知”的一致性保障我把它抽象成了本地事务处理。将来对接微信支付时只需要把“确认支付”这一步替换成调用微信下单接口在回调里完成同样的状态更新逻辑。如果能再进一步在支付前后分别校验订单状态是否允许本次操作并在写支付流水时检查该订单是否已有成功支付记录就可以顺带说一句幂等设计。这已经是网上订餐系统里能拿得出手的纵深了。5. 开发中真正踩过的坑并发、精度、状态机5.1 库存超卖并发下最常见的翻车现场单机单用户测试一切正常为什么需要担心库存超卖因为真实场景里一个系统要同时服务很多用户。假设一个菜只剩1份两个用户同时下单理论上只能成功一个但如果代码是“先查库存、判断够不够、再扣库存”这种三步逻辑并发情况下就会出问题用户A查库存剩余1够用户B查库存剩余1够用户A扣库存变成0用户B扣库存变成-1。这就是超卖。而毕设答辩里这个问题几乎是必问题。你要么没做并发控制老师问住了要么做了哪怕只是最简单的乐观锁都能让老师看到你的工程意识。我用的方案很简单不引入Redis分布式锁就在SQL层面解决UPDATE dish SET stock stock - #{quantity} WHERE id #{id} AND stock #{quantity}这行SQL返回影响行数如果为0说明库存不够本次扣减失败抛异常触发事务回滚。原理是通过数据库的行锁保证并发安全的扣减。关键点在于 WHERE 条件里带上了 stock #{quantity}在更新前就校验了库存足够而不是先查询再更新。这是我整个项目里最值得在答辩时讲的一个点从“查询再更新”到“带条件更新”仅仅是设计思路的转变但效果完全不同。5.2 金额计算double的锅BigDecimal来背价格字段在数据库里我用 decimal(10,2)在Java实体里我用 BigDecimal这两个决定如果在整个项目里贯彻下去金额精度问题就不会踩雷。怕就怕有的人数据库用decimal、Java里用double算总价的时候直接 double total price * quantity那算到小数位就可能出现 0.10.20.30000000000000004 这种离谱结果。有同学可能觉得差一点点没所谓但在实际业务里金额对不上账是大事故金额计算也要求绝对精确。简单的规则数据库金额字段用decimal不用float/doubleJava实体用BigDecimal不用double前端传金额参数用字符串或分为单位避免浮点数序列化误差BigDecimal构造时用字符串构造new BigDecimal(19.9)不要new BigDecimal(19.9)。最后一条很多人不知道。new BigDecimal(19.9) 的底层其实是把浮点数的二进制近似值原样带进来结果还是带了一堆小数而传字符串“19.9”才是精确的。这属于那种“看API文档根本注意不到、踩过一次再也不忘”的坑。5.3 状态流转混乱给订单状态写一张“许可表”项目做到后面订单状态一多就非常容易出现“状态随便跳”的bug。比如待支付的订单直接变成已完成或者已取消的订单又被接单。问题根源在于每个操作都在无脑更新状态没有任何约束。我的做法是定义一张状态流转许可表每个状态允许向哪些状态流转写清楚后再实现通用的状态更新方法public class OrderStatusTransfer { private static final MapInteger, SetInteger ALLOWED_TRANSFER new HashMap(); static { // 待支付可取消可支付 ALLOWED_TRANSFER.put(OrderStatus.UNPAID, new HashSet(Arrays.asList(OrderStatus.CANCELLED, OrderStatus.PAID))); // 已支付可取消退款可接单 ALLOWED_TRANSFER.put(OrderStatus.PAID, new HashSet(Arrays.asList(OrderStatus.REFUNDED, OrderStatus.ACCEPTED))); // 已接单可开始配送 ALLOWED_TRANSFER.put(OrderStatus.ACCEPTED, new HashSet(Arrays.asList(OrderStatus.DELIVERING))); // 配送中可完成 ALLOWED_TRANSFER.put(OrderStatus.DELIVERING, new HashSet(Arrays.asList(OrderStatus.COMPLETED))); // 已完成、已取消、已退款终态不允许再变更 } public static void checkTransfer(int from, int to) { SetInteger allowed ALLOWED_TRANSFER.get(from); if (allowed null || !allowed.contains(to)) { throw new BusinessException(非法的订单状态流转); } } }然后所有更新订单状态的地方都先调用 checkTransfer(当前状态, 目标状态)再执行update。这个设计在答辩时非常好讲如何用预定义的状态机约束业务流转防止非法操作。5.4 登录状态Session还是JWT用户登录后怎么维持状态是个必写的模块也是个答辩必问题。两种方案各有优势。Session方案是传统JavaWeb的思路登录成功后把用户信息放Session里后续请求通过拦截器从Session取用户ID。实现简单配合Spring Boot的拦截器很容易做但问题在分布式环境下Session不共享需要Redis做Session共享。JWT方案是无状态认证登录成功后签发一个Token前端存起来后续请求放在请求头里后端解析Token获取用户信息。优点是不依赖服务端存储、天然支持水平扩展但缺陷是Token一旦签发到期前无法主动失效需要额外维护黑名单。毕设项目怎么选如果做的是单体应用我觉得Session就够代码量最少、逻辑最好讲。但如果你不想在答辩时被追问“Session在分布式环境下怎么办”直接用JWT把Redis加进来做登录黑名单和验证码这个架构就立起来了。我用JWT时的具体做法Component public class JwtUtil { Value(${jwt.secret}) private String secret; Value(${jwt.expire}) private Long expire; // 单位秒 public String createToken(Long userId, String username) { return Jwts.builder() .setSubject(username) .claim(userId, userId) .setIssuedAt(new Date()) .setExpiration(new Date(System.currentTimeMillis() expire * 1000)) .signWith(SignatureAlgorithm.HS256, secret) .compact(); } public Claims parseToken(String token) { return Jwts.parser().setSigningKey(secret) .parseClaimsJws(token).getBody(); } }再配一个拦截器在进入Controller之前校验Token把解析出来的用户ID放入ThreadLocal或请求属性中。代码量不大但整个系统的“当前用户从哪来”这个问题就被统一解决了。6. 答辩演示与常见追问把做过的东西讲成自己的6.1 演示流程怎么编排最加分产品做完了答辩演示的顺序很讲究。不要一上来就展示后台管理的增删改查那是最不吸引人的部分。按业务故事来走第一步演示用户注册登录强调密码不是明文存储的用的是加密算法。 第二步打开首页展示菜品按分类展示的效果随便点开一个菜品强调库存字段和上下架状态。 第三步加购物车结算填写地址提交订单重点展示下单成功后订单金额计算正确、进入待支付状态。 第四步模拟支付看到订单状态变成已支付强调支付流程和状态一致性设计。 第五步切换到商家后台看到新订单接单、配送每一步都切回用户端刷新展示订单状态同步变化。 第六步最后展示历史订单列表和订单详情说明明细表里的菜品名称是快照数据。这套流程走下来等于把整个系统的数据库设计、业务逻辑、状态机控制全部串联了一遍而且每一步都有对应的页面反馈。演示过程中顺便说一句“这个操作涉及到事务回滚”“这个状态变化走的是状态机校验”含金量就出来了。6.2 高频追问与应对思路我把自己当评委列出几个必问的问题你提前把答案准备扎实为什么选择Spring Boot而不是SSH或者Spring Cloud答Spring Boot简化了配置适合快速构建单体应用本次毕设重点在业务完整性单体架构足够承载Spring Cloud的微服务治理在这个场景里属于过度设计但我了解其设计思想后续扩展时可以按业务拆分成服务。你的系统如何防止库存超卖答在扣减库存的SQL中用 stock #{quantity} 作为条件通过数据库行锁保证并发安全。如果未来并发量更高可以引入Redislua脚本实现原子扣减或使用消息队列削峰。订单和支付如何保证数据一致答在单体应用中订单创建、支付状态更新都在一个数据库事务里完成保证强一致如果拆分为微服务则采用本地消息表或事务消息最终一致性。你怎么理解数据库事务的隔离级别答我用的是MySQL默认的REPEATABLE READ在这个业务场景里因为关键操作都通过SQL原子更新和行锁保证安全隔离级别满足需求。更深一层可以说明MVCC机制的原理。这些问题其实没有标准答案老师考察的是你有没有自己的思考逻辑。哪怕答得不完美只要你能围绕“选型理由、对比方案、改进方向”说清楚就比背下来的八股文强一百倍。6.3 还能往哪个方向扩展如果时间充裕想给项目加亮点我给你三个性价比最高的方向一是加Redis缓存。首页菜品列表、菜品分类这些读多写少的数据缓存到Redis里减少数据库压力。这一个点就能在架构图上多画一个组件。二是加WebSocket。商家接单后用户端页面实时弹出“商家已接单”的提醒不需要用户手动刷新。WebSocket的握手、Session管理也是Java面试里偏加分的内容。三是加Excel导出。后台加一个订单报表导出功能用EasyExcel把订单列表导出成Excel文件。这个功能实用性极强操作也不复杂但展示效果非常直观。以上每个扩展都能在答辩时单独讲三分钟而且都是“看得见的实际功能”不是纸上谈兵。最后说点实在的。我在带毕设的过程中发现一个规律最后得高分的往往不是代码炫技最多的而是逻辑最完整、讲得最清楚的。网上订餐系统这个题目功能边界清晰技术栈成熟你只要把数据库设计做扎实、核心下单逻辑的事务和并发控制做对、订单状态机管理好再把答辩演示串成一条业务故事线就已经超过一大批人了。别想着什么都做把核心链路打磨到位比堆功能清单有用得多。
