JavaWeb毕设实战：鲜牛奶订购系统从选题到答辩全攻略

如果你最近在准备 JavaWeb 方向的毕业设计，又纠结题目怎么选，那“鲜牛奶订购系统”这个方向真的可以认真考虑一下。这个题目乍一听像个普通的商城系统，但真正把需求、数据库、订单状态、配送逻辑都理清楚之后，你会发现它比通用商城Demo有意思得多，也更适合写论文、做答辩。我按照“系统+论文+PPT+源码+演示视频”这条完整链路走了一遍，前后踩了不少坑，这篇就把整个项目该怎么做、论文怎么写、材料怎么整理、答辩有哪些坑，全部摊开来讲。

这个项目定的技术栈是经典的 Servlet + JSP + MySQL + Tomcat，也就是常说的 JavaWeb 标准组合。任务是在用户端完成注册登录、牛奶品类浏览、按周期订购、购物车、订单查询和地址维护，在管理端完成商品管理、订单处理、配送安排和用户管理。做完之后我最大的感受是：这个题目的业务复杂度刚刚好，覆盖了 JavaWeb 的核心考点——Session 会话、Filter 拦截器、JDBC 数据库操作、MVC 分层、前端表单交互，同时又不至于让它膨胀成一个做完就想删的“大Demo”。接下来我从选题思路、系统设计、功能实现、论文整理、答辩避坑五个部分，逐一说清楚。

1. 毕设选题思路：鲜牛奶订购系统为什么值得做

1.1 先用业务逻辑说服自己

很多同学选毕设题目，第一反应是找个“看起来好做”的，比如图书管理、学生信息管理。这类题不是不行，是太普通，答辩老师一眼就能猜到整个系统长什么样，提不出亮点也问不出深度。而“鲜牛奶订购系统”在业务上有一个天然优势：场景足够生活化，每天都能接触到，完全不需要向评委解释业务背景；同时它又不像普通商城那样只有一个“下单-发货-收货”的线性流程。

鲜奶订购和普通网购最大的区别在于“周期”和“配送”。普通商城用户下单是一次性行为，买完就结束了；但鲜奶订购往往是“订一个月、每天或隔天配送一瓶”这种周期性服务。订单不只是记录用户买了什么，还要管理配送计划：今天是订单日的哪一天？这瓶奶是明天送还是后天送？用户临时暂停配送怎么办？这些业务细节直接决定了数据库表和订单流程怎么设计。

从答辩角度来看，只要把“周期购”和“配送管理”这两个点讲清楚，系统就和其他人的普通商城彻底区分开了。技术难度没有高多少，但业务复杂度提升了一截，论文里可以写的分析内容也更多。这也是我选题时优先推荐这个方向的核心原因。

1.2 技术选型：Servlet+JSP 是刻意保留的

现在一提到 Java 开发，大多数人默认会用 Spring Boot + MyBatis，为什么我反而选择 Servlet + JSP + JDBC 这套“老技术”？

主要有两个考虑。一是很多高校的 JavaWeb 课程大纲仍然以 Servlet、JSP、Filter、JDBC 为主，毕业设计用自己学过的技术栈来写，代码逻辑更透明，出了问题也知道去哪儿排查。二是在答辩时，老师非常喜欢追问底层原理，如果用 Spring Boot，很容易被问到“自动配置原理”“启动流程”这类比较深的问题；而 Servlet 的生命周期、Filter 的执行顺序、Session 的原理，都是课堂上正经讲过、自己也能说清楚的知识点。做毕设的优先级是“稳定完成、讲得明白”，而不是“技术越新越好”。

当然，并不是说不能加框架。我在系统里采用了 MVC 思想做了简单的分层：Servlet 只做请求接收和转发，业务逻辑单独放到 Service 层，数据库操作统一封装到 Dao 层，JSP 只负责展示。页面用了 Bootstrap + jQuery 做样式和交互。这套结构既保留了对底层机制的可控性，又不会让代码堆成一个“什么都有的大杂烩”，后边写论文画架构图的时候也非常清晰。

2. 系统整体设计：功能模块与数据库结构

2.1 用户端功能模块

用户端是普通用户看到的全部界面，也是论文里功能需求分析的主要素材。我在设计时把功能拆成了六个核心模块，每个模块对应若干页面和接口：

• 用户注册与登录：包含校验用户名是否重复、密码加密存储、登录后 Session 记录用户状态、退出登录销毁 Session。
• 牛奶品类浏览：首页展示牛奶列表，支持按品类筛选（鲜奶、酸奶、儿童奶、常温奶等）、查看商品详情，包括规格、价格、库存、保质期信息。
• 购物车：用户可以将牛奶加入购物车，修改数量、删除条目、查看总价。购物车数据放在数据库中，这样用户换电脑登录也能看到自己的购物车。
• 下单结算：从购物车生成订单，选择配送地址、配送周期（每天送、隔天送、每周几送）、开始日期和结束日期，生成总的订单金额。
• 订单管理：用户可以查看自己的订单列表和详情，取消未支付订单，确认已完成订单，还能查看每个订单对应的配送计划。
• 个人中心：维护收货地址、修改密码、查看账户信息。

2.2 管理端功能模块

管理端面对的是订奶站或配送站的工作人员，功能设计上一定要围绕“订单处理”和“配送安排”展开。我实现了下面这些模块：

• 管理员登录与权限控制：管理员和用户分别走不同的登录入口和后台路径，通过 Filter 统一做登录校验。
• 商品管理：上架、下架牛奶商品，修改价格、库存、描述，处理商品图片上传。
• 订单管理：所有订单的列表查询、按订单号或用户搜索、查看订单详情、修改订单状态。
• 配送管理：根据订单的配送周期自动生成配送计划表，管理员可以选择日期查看当天的配送任务，也可以手动标记“已配送”。
• 用户管理：查看注册用户列表、禁用异常账号。
• 数据看板：简单地统计订单总数、今日配送量、热销商品排行。这里不追求复杂图表，用几个数字和柱状图就能满足论文里“系统测试与展示”的需求。

2.3 数据库表设计详解

数据库是这个项目的核心，表设计直接决定后面代码怎么写。我最终设计了七张表，这里把表结构和设计要点逐一说下。

-- 用户表 CREATE TABLE `t_user` ( `user_id` int(11) NOT NULL AUTO_INCREMENT, `username` varchar(50) NOT NULL, `password` varchar(64) NOT NULL, `phone` varchar(20) DEFAULT NULL, `real_name` varchar(50) DEFAULT NULL, `role` int(11) DEFAULT '1' COMMENT '1:普通用户 2:管理员', `status` int(11) DEFAULT '1' COMMENT '1:正常 0:禁用', `create_time` datetime DEFAULT NULL, PRIMARY KEY (`user_id`), UNIQUE KEY `uk_username` (`username`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- 牛奶商品表 CREATE TABLE `t_product` ( `product_id` int(11) NOT NULL AUTO_INCREMENT, `product_name` varchar(100) NOT NULL, `category` varchar(50) DEFAULT NULL COMMENT '品类：鲜奶/酸奶/儿童奶等', `specification` varchar(50) DEFAULT NULL COMMENT '规格：250ml/500ml/1L', `price` decimal(10,2) NOT NULL, `stock` int(11) DEFAULT '0', `description` varchar(500) DEFAULT NULL, `image_url` varchar(200) DEFAULT NULL, `status` int(11) DEFAULT '1' COMMENT '1:上架 0:下架', `create_time` datetime DEFAULT NULL, PRIMARY KEY (`product_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- 购物车表 CREATE TABLE `t_cart` ( `cart_id` int(11) NOT NULL AUTO_INCREMENT, `user_id` int(11) NOT NULL, `product_id` int(11) NOT NULL, `quantity` int(11) DEFAULT '1', `add_time` datetime DEFAULT NULL, PRIMARY KEY (`cart_id`), UNIQUE KEY `uk_user_product` (`user_id`,`product_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- 配送地址表 CREATE TABLE `t_address` ( `address_id` int(11) NOT NULL AUTO_INCREMENT, `user_id` int(11) NOT NULL, `receiver_name` varchar(50) DEFAULT NULL, `receiver_phone` varchar(20) DEFAULT NULL, `province` varchar(50) DEFAULT NULL, `city` varchar(50) DEFAULT NULL, `district` varchar(50) DEFAULT NULL, `detail_address` varchar(200) DEFAULT NULL, `is_default` int(11) DEFAULT '0', PRIMARY KEY (`address_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- 订单主表 CREATE TABLE `t_order` ( `order_id` int(11) NOT NULL AUTO_INCREMENT, `order_no` varchar(32) NOT NULL COMMENT '业务订单号', `user_id` int(11) NOT NULL, `address_id` int(11) DEFAULT NULL, `total_amount` decimal(10,2) DEFAULT '0.00', `status` int(11) DEFAULT '0' COMMENT '0:待支付 1:已支付 2:制作中 3:配送中 4:已完成 5:已取消', `start_date` date DEFAULT NULL COMMENT '配送开始日期', `end_date` date DEFAULT NULL COMMENT '配送结束日期', `delivery_type` varchar(20) DEFAULT NULL COMMENT 'daily:每日送 隔天:every_other_day 每周:weekly', `create_time` datetime DEFAULT NULL, `pay_time` datetime DEFAULT NULL, PRIMARY KEY (`order_id`), UNIQUE KEY `uk_order_no` (`order_no`), KEY `idx_user_id` (`user_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- 订单明细表 CREATE TABLE `t_order_item` ( `item_id` int(11) NOT NULL AUTO_INCREMENT, `order_id` int(11) NOT NULL, `product_id` int(11) NOT NULL, `product_name` varchar(100) DEFAULT NULL, `price` decimal(10,2) DEFAULT NULL, `quantity` int(11) DEFAULT NULL, `subtotal` decimal(10,2) DEFAULT NULL, PRIMARY KEY (`item_id`), KEY `idx_order_id` (`order_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- 配送计划表 CREATE TABLE `t_delivery_plan` ( `plan_id` int(11) NOT NULL AUTO_INCREMENT, `order_id` int(11) NOT NULL, `order_item_id` int(11) DEFAULT NULL, `plan_date` date DEFAULT NULL COMMENT '计划配送日期', `status` int(11) DEFAULT '0' COMMENT '0:待配送 1:已配送 2:暂停', `actual_time` datetime DEFAULT NULL, PRIMARY KEY (`plan_id`), KEY `idx_plan_date` (`plan_date`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这些表的关系很清晰：用户和地址是一对多，订单和订单明细是一对多，一个订单根据配送周期生成多条配送计划记录。重点想提醒两个设计细节。

第一个细节是订单主表里存了start_date、end_date和delivery_type三个字段。这三个字段决定了“从哪天开始送到哪天结束、多久送一次”，是核心业务逻辑的关键。用户下单时，通过后端服务根据这几个字段生成配送计划记录，这样才能让配送管理模块有数据可看。

第二个细节是订单明细表里冗余保存了product_name和price。这是故意做的冗余，因为订单一旦生成，商品套餐后来就算改名或者调价，订单里也应该保留下单那一刻的信息。不要图省事去关联查询商品表，否则历史订单会出现名称对不上的问题。

2.4 前后台权限控制与公共模块

权限控制用最直接的方式实现：用户表里加一个role字段，1 表示普通用户，2 表示管理员。用户登录后把用户对象塞进 Session，后台管理路径全部经过一个 Filter 判断：session.getAttribute("user")为空就跳登录页，非管理员就拦截提示无权限。这个方案虽然朴素，但胜在逻辑清晰，论文里画个流程图就能说清楚。

公共模块还包括分页、文件上传、统一响应对象。分页我是自己写了一个简单的 PageBean，接收 currentPage 和 pageSize，查询总数后计算总页数。实际写完发现，分页的代码量不小，但可以复用，订单管理、用户管理、商品管理都用同一套逻辑，工作量摊薄之后就还好。

3. 核心功能模块的实现过程

3.1 登录认证与 Session 管理

登录这个模块看似简单，却是我建议优先写的部分，因为其它所有功能都依赖登录状态。密码存储时不要用明文，至少用 MD5，更稳妥一点的做法是 MD5 加盐。下面这段代码是登录 Servlet 的核心逻辑：

@WebServlet("/user/login") public class LoginServlet extends HttpServlet { @Override protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { String username = req.getParameter("username"); String password = req.getParameter("password"); User user = userDao.findByUsername(username); if (user == null) { req.setAttribute("error", "用户不存在"); req.getRequestDispatcher("/login.jsp").forward(req, resp); return; } // 实际项目中建议对 password 做 md5 后再比对 if (!user.getPassword().equals(password)) { req.setAttribute("error", "密码错误"); req.getRequestDispatcher("/login.jsp").forward(req, resp); return; } if (user.getStatus() == 0) { req.setAttribute("error", "账号已被禁用"); req.getRequestDispatcher("/login.jsp").forward(req, resp); return; } // 登录成功，保存 Session HttpSession session = req.getSession(); session.setAttribute("user", user); session.setMaxInactiveInterval(60 * 30); if (user.getRole() == 2) { resp.sendRedirect(req.getContextPath() + "/admin/index"); } else { resp.sendRedirect(req.getContextPath() + "/product/list"); } } }

权限拦截的 Filter 是另一个容易被忽略的细节。这里有一个坑：如果只拦截后台路径，用户端页面就没法做“未登录拦截”；如果拦截所有页面，那么登录页、注册页、静态资源（CSS/JS/图片）也要放行。我当时是在 Filter 里维护了一个放行路径列表，包含/login.jsp、/register.jsp、/user/login、/user/register、/css/*、/js/*、/images/*，其余路径全部校验 Session。这样前后台的拦截逻辑用一个 Filter 就能覆盖。

3.2 购物车与下单结算的细节

购物车我选择了直接存数据库的方案。很多教程教使用 Session 存购物车，这样做刷新和换设备都会丢数据，体验太差。数据库方案每操作一次都要读写表，性能上有损耗，但对于课程设计规模的项目完全没有问题。

加购接口的逻辑是：先查购物车表里有没有该用户的同商品记录，有就数量加一，没有就插入新记录。购物车列表页展示的时候关联商品表查价格、图片、剩余库存，同时计算总价。修改数量和删除都是通过 AJAX 请求完成，页面不刷新。

下单结算环节是最复杂的一个流程。用户点击“去结算”后，系统要一次性完成这么几件事：

• 从购物车查出用户勾选的商品条目。
• 校验商品状态和库存，库存不足的条目要明确提示。
• 计算订单总金额。
• 创建一个总状态为“待支付”的订单。
• 把购物车条目批量转成订单明细。
• 清空已下单的购物车条目。
• 根据用户选择的配送周期和起止日期，生成配送计划。

这里一定要用事务。我刚开始实现的时候因为偷懒，直接用 DAO 一层层调用，结果中途出异常时购物车清空了、订单却创建失败，用户钱没了奶也没订上。后来用Connection的setAutoCommit(false)包住整个流程，最后统一 commit，出错就 rollback，问题才彻底解决。如果你是参考或修改别人的开源代码，第一件事就是检查这段下单逻辑有没有加事务。

try (Connection conn = DbUtil.getConnection()) { conn.setAutoCommit(false); OrderDao orderDao = new OrderDao(conn); OrderItemDao orderItemDao = new OrderItemDao(conn); DeliveryPlanDao deliveryPlanDao = new DeliveryPlanDao(conn); CartDao cartDao = new CartDao(conn); int orderId = orderDao.insert(order); for (CartItem item : cartItems) { orderItemDao.insert(orderId, item); deliveryPlanDao.generatePlan(orderId, item, startDate, endDate, deliveryType); } cartDao.clearCart(userId, productIds); conn.commit(); } catch (Exception e) { conn.rollback(); throw new RuntimeException("下单失败，请重试"); }

3.3 订单状态机与配送计划生成

订单状态是我在答辩时重点讲的一个点。我把状态设计成六个值，用整数存，页面显示时转换成对应文字：

状态流转的方向是单向的，从 0 往后递增，不允许跳跃，也不允许回退。这个规则在代码里有过滤判断，不是前端按钮禁用那套，而是后端 Service 层每个操作方法都会检查当前状态是否符合预期，状态不符合就抛出业务异常。比如“已取消”的订单不能再次支付，“已完成”的订单不能取消。这样设计最大的好处是业务规则明确，论文里画状态图特别方便。

配送计划生成是另一个核心逻辑。用户下单选择了“每天送、从下周一开始、共送 30 天”，系统就要生成 30 条配送计划记录。这里我用了一个循环，按delivery_type决定步长：

public void generatePlan(int orderId, OrderItem item, LocalDate start, LocalDate end, String type) { int step = switchTypeToStep(type); // daily:1, every_other_day:2, weekly:7 LocalDate cur = start; while (!cur.isAfter(end)) { insertPlan(orderId, item, cur); cur = cur.plusDays(step); } }

这个逻辑本身不复杂，真正麻烦的是“用户中途暂停配送”。后来我加了一个简单的方案：用户可以在配送计划列表里点击“暂停本周”，后台把本周未配送的 plan 记录状态改成 2，管理员在配送任务里就不会看到。这个需求是真实订奶用户经常提起的，写进论文里也是一个很好的业务亮点。

3.4 后台管理的实现思路

管理端页面我单独放到/admin目录下，路径以/admin/*开头，由 Filter 统一校验管理员身份。商品管理的增删改查是标准套路，重点是图片上传。图片我保存到项目本地的uploads目录，数据库只存相对路径uploads/xxx.jpg。页面展示时通过一个专门的 ImageServlet 读取文件流返回，这样比绝对路径更稳，不会因为项目目录迁移而失效。

订单管理页面默认按“待处理”排序，管理员可以看到用户下的所有订单。管理员操作的核心是状态修改按钮，比如“确认生产”“标记配送”“确认送达”。配送管理页面按日期查询当天的配送计划，展示配送地址、牛奶品类、数量，管理员勾选完成即可。这个页面演示效果相当直观，因为能真真切切看到“今天要送哪几家、送多少瓶”，比单纯操作订单列表有说服力得多。

4. 论文、PPT 和演示视频这样组织最省心

4.1 毕业论文的框架逻辑

很多同学写毕业论文容易写成“用户说明书”，大段贴代码、放截图，完全没有论文的样子。我的建议是论文按七章结构走，每一章解决一个明确的问题：

第一章绪论交代背景和意义，重点回答“为什么要做一个鲜牛奶订购系统”；第二章相关技术介绍，把 Servlet、JSP、MySQL、Tomcat 的原理说清楚，不要写成名词堆砌；第三章需求分析，画用例图，写功能需求和非功能需求；第四章系统设计，画总体架构图、功能模块图、数据库 ER 图和表结构；第五章系统实现，每小节对应一个功能模块，先写实现思路，再放核心代码和截图，最后说一下这个模块解决了什么问题；第六章系统测试，写测试环境、测试用例、测试结果；第七章总结与展望。

论文里所有图表一定要自己画。用绘图工具画用例图、时序图、状态图，不要截取其他博客的图或直接粘贴别人的图，答辩老师一眼就能看出来，而且查重环节图表重复也可能带来风险。核心代码不要整段贴，贴关键方法就好，既体现工作量，又不显得凑字数。

4.2 常见写作误区：别把论文写成代码注释

我见过太多论文的“系统实现”章节写成了“这个代码是做什么的、那个方法是做什么的”。老师想看的是设计思路和关键问题的解决过程，不是代码解释。以订单状态为例，好的写法是先说明为什么要分这几个状态、每个状态之间靠什么机制流转，然后再配一个状态图，最后截一张后台管理界面的订单列表图。这样的叙述有一条完整的逻辑线，答辩时也容易顺着讲。

页数方面，本科毕业论文一般要求正文在 1.2 万字以上。我的经验是：需求分析、系统设计、系统实现、系统测试这四个章节是凑字数的主力。把用例描述表做出来，把数据库每一张表的字段含义列清楚，把测试用例写详细，字数自然就到了。反而绪论、技术介绍不要拼命扯，老师最反感谢在技术介绍里写一堆课本原话。

4.3 PPT 与演示视频的准备技巧

答辩 PPT 我建议控制在 12 到 15 页。首页放题目和姓名信息，第二页放目录，接着按“背景与意义-技术栈-需求分析-系统架构-核心功能演示-数据库设计-测试情况-总结与展望”的顺序。每页文字不要超过六行，核心内容用截图和图表说话，尤其是系统界面截图和数据库关系图，比干巴巴的文字有说服力得多。配色就用简洁的白底深色文字，学校投影仪一般比较老旧，颜色太浅容易被“吃掉”。

演示视频是很多老师会要求交的材料，时长控制在五分钟左右。我的录制顺序是：先展示用户从注册登录、浏览牛奶、加购物车、下单、查看订单的完整流程，再切到管理后台，展示商品管理、处理订单、查看配送计划。录之前一定先写脚本，把每一步点击、每一句旁白都写在纸上，不然录到一半想不起下一步操作，视频会很碎。录屏工具可以用常用的免费录屏软件，分辨率建议设置成 1280x720 以上，声音清晰些，背景音乐可加可不加，加了音量一定要压过旁白太多。

5. 常见问题与排错实录

5.1 环境和版本相关的坑

JavaWeb 项目最怕的就是环境不一致。我在搭建时遇到过一个典型问题：本地 JDK 用 8，Tomcat 用的 9，MySQL 用的 8.0，结果 JDBC 驱动版本没对齐，导致数据库连接报错。后来把 MySQL Connector/J 统一换成 8.0 系列的驱动，同时在连接 URL 上加useSSL=false&serverTimezone=Asia/Shanghai才解决。

建议你从一开始就固定版本：JDK 8 + Tomcat 8.5 + MySQL 5.7 + Maven 3.6，这一套组合比较稳定，网上资料也多。如果是自己电脑，可以装一个免安装版的 Tomcat，再配一个绿色版 MySQL，避免卸载残留导致端口冲突。用 IDE 内嵌的 Tomcat 也可以，但答辩现场如果换电脑部署，还是独立 Tomcat 更稳妥。

5.2 中文乱码问题：三处设置缺一不可

JavaWeb 的中文乱码是老生常谈，但每次都会有人踩。我的经验是总共要检查三层：数据库连接 URL 的编码参数、JSP 页面顶部的pageEncoding和contentType、Servlet 里读写请求时的编码设置。三个地方有一个漏掉，就可能出现中文乱码。

request.setCharacterEncoding("UTF-8"); response.setContentType("text/html;charset=UTF-8");

jdbc:mysql://localhost:3306/milk_db?useUnicode=true&characterEncoding=UTF-8&useSSL=false&serverTimezone=Asia/Shanghai

数据库建表时统一用utf8mb4，不要用默认的latin1，这个坑排查起来很隐蔽，因为前端显示正常，存进 MySQL 之后查出来就变成问号，多半就是表字符集的问题。

5.3 订单与配送逻辑的运行时异常

我在调试配送计划生成的时候，遇到过循环日期死循环的情况。原因是endDate的格式没有正确转换，导致 LocalDate 比较始终不满足结束条件。这里建议统一在 Service 层做日期转换，用DateTimeFormatter固定格式，不要把解析逻辑散落在各个 Servlet 里。

另一个容易出问题的地方是并发下单。虽然课程设计阶段并发量不大，但如果用户在页面狂点两次提交，就可能重复下单。我的处理方案是在前端点击下单后把按钮置灰禁用，后端再判断一次：同一用户 5 秒内的相同订单直接拒绝。这是双保险，前端体验和后端校验各有各的作用。如果你想让系统更严谨一点，也可以给订单表加一个用户维度的幂等标识字段。

5.4 答辩演示时的现场注意事项

答辩翻车往往不是系统功能有问题，而是演示准备不足。建议在正式答辩前一天，把项目部署好，完整走一遍演示流程，包括注册新账号、登录、下单、后台操作。有几个细节要注意：

• 演示用的数据库可以先清掉测试数据，准备几组干净的数据，包括一个普通用户账号、一个管理员账号、几个牛奶商品、一份未支付订单和一份待配送订单。
• 提前把数据恢复脚本写好，如果答辩现场不小心把数据搞乱了，一键恢复比手工重新录入从容得多。
• 投影分辨率可能和笔记本不一致，浏览器缩放比例要提前测试，确保字体足够大。
• 不要依赖校园网环境，数据库、Tomcat 都放本地，尽量独立运行。

我在实际调试中还发现一个容易忽略的细节：演示时尽量不要当着评委的面真输入密码登录，可以提前登录好再展示，或者用一个弱密码快速演示。这样显得流畅，也减少被现场设备键盘布局坑到的概率。

做完整套项目再回头看，鲜牛奶订购系统这个题目最有价值的地方在于：它迫使你把一个看起来普通的需求真正往下拆一层——从用户周期购的选择，到配送计划的逐条生成，再到后台每天的配送任务管理，每一步都有实实在在的业务落点。代码量不算大，但每个模块都在解决具体问题。论文写起来也不缺素材，要画图有图，要流程有流程，要测试有真实用例。如果正在准备毕设，或者想找一个既稳妥又有亮点的 JavaWeb 题目，这个方向可以放心选。

最后再分享一个制作演示视频时的小经验：千万不要录制完就直接交。先把视频从头到尾看一遍，重点观察模块切换时有没有卡顿、弹窗提示是否被遮挡、页面有没有无意义的等待时间。一份干净利落的演示视频，有时候比几百行代码更能让评委快速信服。