企业官网建设流程全解析

做Java Web毕业设计，十个人里有八个会选管理系统，而餐厅点餐系统又是其中热度最高的一类。原因很简单：业务链条完整、角色分明、增删改查覆盖全面，还能自然带出购物车、订单、权限这些“有技术含量”的点。我今年带过的学生里，至少有五个选了JSP基于Java的餐厅点餐系统这个题目。说实话，这个题目放在2025年看确实不算新，但正因为不新，网上资料多、踩坑记录全、答辩问题也可预测，反而更容易做出一个完整、能跑、能讲清楚的系统。这篇就按我实际带毕设的思路，把这个题目从头到尾拆一遍，从功能设计到数据库，从核心代码到部署避坑，全流程讲清楚。

这篇文章适合正在做这个题目的毕业生，也适合想用JSP+Servlet+JavaBean传统技术栈快速搭一个Web项目的初学者。我默认你看过Java基础，知道JDBC是什么，但不一定真的完整做过一个Web项目。文中会给出可以直接抄的代码片段、表结构和排查思路，但不会贴一整份源码——真给你整份源码你也背不下来，还不如把关键逻辑吃透。

1. 项目概述与选题价值

1.1 这个系统解决的真实问题

餐厅点餐系统听起来很宽泛，但在毕业设计这个场景下，它通常要做的是把线下餐厅的“人工点餐—后厨出餐—前台结账”流程搬到线上。具体到实际功能，一般包含几个核心场景：顾客进店后扫码或者坐在座位上浏览菜品，选择菜品加入购物车，确认下单；后厨或者前台能看到新订单，标记出餐状态；管理员在后台维护菜品分类、菜品信息、价格、图片，以及查看营业相关的订单统计。

很多同学一开始容易把需求想得太大，什么预订桌位、会员积分、外卖配送、库存管理全塞进去。我的建议是别这么干。毕业设计拼的不是功能多，而是每个功能是否闭环、逻辑是否自洽、答辩时能否讲清楚。一个“顾客点餐+后台管理”的闭环，配合登录鉴权、购物车、订单状态流转、简单的数据统计，已经足够支撑一篇中等偏上的毕业论文了。你把它做深、做稳，比铺开十个半成品功能要实用得多。

这个项目的经典使用流程是这样的：餐厅管理员先在后台录入菜品分类和菜品信息，包括名称、价格、简介和图片；顾客打开系统首页浏览菜品，可以按分类筛选，把想吃的菜加入购物车；购物车页面可以修改数量、删除菜品，确认无误后填写桌号或者备注并提交订单；订单生成后，餐厅端（管理员）在订单列表里看到新订单，点击“接单”或者“完成”；最后管理员可以在统计页面看到菜品销量和每日营业额。完整走下来，业务闭环就成立了。

1.2 为什么选JSP+Java做毕设

我知道现在Spring Boot已经很普及，很多学生上来就想用Spring Boot + Vue搞前后端分离。但如果你平时只是跟着教程写过几个CRUD，没有系统学过Spring家族，答辩时老师一问“Spring Boot自动装配原理”“依赖注入怎么工作的”，很容易卡壳。JSP+Servlet+JavaBean这种传统技术栈的好处是，它足够“原始”和“透明”。一次请求从浏览器到JSP再到Servlet再到数据库，每一层干了什么你都能看得清清楚楚，不依赖框架封装的黑魔法。

另外，很多学校的课程设计、Java Web实训还在用这套技术栈，教材和实验指导书都是围绕JSP写的。用学校熟悉的栈做毕设，指导老师给意见也更有针对性，答辩通过率更高。再加上JSP本质上就是Java代码嵌套HTML，调试起来直观，页面逻辑都在眼前，不像前后端分离项目还要同时排查前端跨域、后端接口、打包部署三层问题。

有人会问，JSP是不是过时了？从工业界看，确实不是主流新项目的第一选择，但作为教学和毕设，它依然是一个很合适的载体。它能让你真正理解HTTP请求-响应模型、Session会话管理、Filter过滤器、JDBC数据库访问这些Web开发底层知识。这些知识换个框架照样用，而且面试时也经常被问到。所以，选JSP做毕设不是“落后”，而是用最简单的手段把Web开发的核心原理做扎实。

2. 功能模块与系统架构

2.1 角色划分与权限模型

餐厅点餐系统的角色划分，最常见的做法是两种角色：普通用户（顾客）和系统管理员。有些题目还会拆出“收银员”“后厨”这些角色，但角色越多，权限控制越复杂，论文和答辩的负担也越大。我建议做两种角色就够，把顾客端和管理端分别做成不同的页面入口，各走各的逻辑。

权限模型上用最经典的做法：User表里加一个role字段，1表示管理员，0表示普通用户。登录成功后把这个用户对象放进Session，然后通过Filter统一拦截需要权限的请求。比如后台管理页面统一放在/admin/路径下，那么Filter就只拦截这个路径，检查Session里的登录用户角色是否为管理员，不是就重定向到登录页。顾客端页面一般不做强拦截，但下单、查看订单这些操作需要登录，所以在购物车提交和订单查询的Servlet里单独校验Session即可。

这种“路径前缀+角色判断”的鉴权方式写起来简单，理解起来也直观，比用Spring Security那套过滤器链更适合毕设阶段。你不需要引入复杂权限框架，就能在答辩时讲清楚“我是怎么防止普通用户直接访问管理页面的”这个问题。

2.2 功能清单与页面流转

具体功能拆成两端来看会清晰很多。顾客端的核心页面是：登录注册页、菜品列表页、菜品详情页（如果需要的话）、购物车页面、提交订单页、我的订单页。管理端的核心页面是：管理员登录页、后台首页（带统计信息）、菜品分类管理页、菜品管理页、订单管理页。

顾客端的页面流转是这样的：未登录用户打开系统，默认跳到登录页，注册后自动登录；登录后进入菜品列表页，顶部是分类导航，中间是菜品卡片，每个卡片上有“加入购物车”按钮；点击购物车图标进入购物车页，可以增删菜品、清空购物车、提交订单；提交订单时选择或填写桌号、备注，生成订单后跳转到“我的订单”页面，能看到订单状态；管理员在后台看到新订单后更新状态，顾客端刷新页面就能看到状态变化。

管理端的流转相对简单：登录后进入后台首页，看到菜品总数、今日订单数、今日营业额这四个核心数字；然后按需进入分类管理或菜品管理页，进行分类的增删改、菜品的增删改，菜品编辑里包含图片上传；订单管理页列出所有订单，按状态筛选，可以点击“接单”“完成”按钮改变状态。整个流程不要复杂化，页面之间通过超链接和Servlet重定向串联即可。

3. 数据库设计与核心表结构

3.1 数据表总体规划

数据库设计是论文里的重头戏，也是答辩老师喜欢深挖的部分。餐厅点餐系统最少需要四张表：用户表t_user、菜品分类表t_category、菜品表t_dish、订单表t_order。如果希望订单菜品关系更规范一些，可以再加一张订单明细表t_order_item，记录每个订单包含哪些菜品、数量、单价。加这张表是标准的“先设计后优化”思路，论文里画ER图的时候也更好看、更规范。

表与表之间的核心关系是：分类表与菜品表是一对多关系，一个分类下有多个菜品；用户表与订单表是一对多关系，一个用户可以下多个订单；订单表与订单明细表是一对多关系，一个订单包含多个菜品明细；菜品表与订单明细表是一对多关系，一个菜品可以出现在多个订单明细里。这些关系在数据库里通过外键逻辑维持，代码里通过关联查询体现。千万不要在数据库物理层面强行加一堆外键约束，毕设项目增删改查频繁，外键约束一旦触发报错，排查起来很绕，逻辑上保证关联即可。

3.2 核心表字段与关系说明

t_user表：主键id（自增）、username（用户名）、password（密码）、role（角色，1管理员0顾客）、realname（真实姓名）、phone（手机号）、create_time（注册时间）。密码我建议至少做一次MD5加密存储，不要明文存，答辩时这也算一个亮点。注意MD5本身不是安全的加密算法，但毕设阶段能说清楚“我做了密码加密存储，防止数据库泄露后密码直接暴露”就够了。

t_category表：id、name（分类名）、sort（排序号，控制前端展示顺序）、create_time。这个表字段不多，但很体现细节，比如按sort字段排序展示分类，比按id排序更专业。

t_dish表：id、category_id（关联分类表id）、name、price（单价，用DECIMAL(10,2)）、image（图片路径，存相对路径如/uploads/xxx.jpg）、description（描述）、sales（销量，冗余字段）、status（上下架状态，1上架0下架）、create_time。price用DECIMAL不用FLOAT，这是数据库基础规范，答辩时被问到要能答上来。

t_order表：id、order_no（订单号）、user_id（下单用户id）、table_no（桌号）、total_amount（总金额）、status（状态：0待接单，1已接单，2已完成，3已取消）、remark（备注）、create_time。订单号用时间戳加随机数生成，格式类似20250512153012345，可以讲一下为什么要用字符串而不是自增id做业务标识，因为订单号要暴露给用户且需要保证唯一、不易猜测。

t_order_item表：id、order_id、dish_id、dish_name（冗余菜品名，防止菜品被删后订单明细没名字）、price（下单时的单价快照）、quantity（数量）、subtotal（小计）。这个表设计时有一个关键点要记住：dish_name和price一定要冗余存一份，不能通过join去查实时的菜品表，因为菜品价格可能会改、菜品可能被删，而订单是历史记录，必须保留下单当时的快照。

4. 核心代码实现与关键逻辑

4.1 登录与权限控制

登录逻辑是这次开发的第一个关键点。流程是：用户在登录页输入用户名和密码，表单提交到LoginServlet；Servlet里调用UserDao根据用户名查用户，比对密码（先对用户输入的密码做MD5加密再和数据库里的密文比对）；比对成功则把用户对象放入Session，再判断角色跳转到对应首页；失败则返回登录页并携带错误提示。

登录Servlet的核心代码框架大概是这样的：

@WebServlet("/login") public class LoginServlet extends HttpServlet { private UserDao userDao = new UserDao(); @Override protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { String username = req.getParameter("username"); String password = MD5Util.md5(req.getParameter("password")); User user = userDao.findByUsername(username); if (user != null && user.getPassword().equals(password)) { req.getSession().setAttribute("loginUser", user); if (user.getRole() == 1) { resp.sendRedirect("admin/index.jsp"); } else { resp.sendRedirect("index.jsp"); } } else { req.setAttribute("error", "用户名或密码错误"); req.getRequestDispatcher("login.jsp").forward(req, resp); } } }

这里要提醒你一个很多新手都会犯的错误：查用户时用username作为唯一条件，如果数据库里没有对username建唯一索引，可能查出多个用户，然后findByUsername返回第一个，逻辑上就有隐患。建表时记得给username加唯一约束。

权限控制我建议用一个AuthFilter统一处理，代码如下：

@WebFilter("/admin/*") public class AuthFilter implements Filter { @Override public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { HttpServletRequest req = (HttpServletRequest) request; HttpServletResponse resp = (HttpServletResponse) response; HttpSession session = req.getSession(); User user = (User) session.getAttribute("loginUser"); if (user == null || user.getRole() != 1) { resp.sendRedirect(req.getContextPath() + "/login.jsp"); return; } chain.doFilter(request, response); } }

这段代码短小精悍，但已经把“会话校验+角色校验+未登录跳转”三个核心逻辑都覆盖了。把管理后台所有页面放在/admin/目录下，这个Filter就能保护所有管理页面。如果你还想保护顾客端的“我的订单”页面，同理再写一个Filter拦截/myOrder相关路径即可。

4.2 点餐下单与购物车逻辑

购物车是餐厅点餐系统里最容易写乱的部分。不少同学喜欢在数据库建一张购物车表，把顾客加购的每一件商品都实时存表，结果数据库里临时数据堆积，还要处理用户未登录时购物车怎么合并的问题，非常麻烦。

我的建议是：购物车用Session实现，本质上就是一个Map<Dish, Integer>或者Map<Integer, Integer>，键是菜品id，值是数量。用户点击“加入购物车”时，前端把菜品id传到CartServlet，Servlet把这个id存进Session里的购物车Map。这种做法的好处是简单、直观、无需建表，而且完全符合“购物车是临时性数据”的业务属性。只有用户真正提交订单时，才把购物车里的数据持久化到数据库的订单表和订单明细表。

购物车加入菜品的核心逻辑可以这样写：

@WebServlet("/cart/add") public class CartAddServlet extends HttpServlet { @Override protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { int dishId = Integer.parseInt(req.getParameter("dishId")); HttpSession session = req.getSession(); Map<Integer, Integer> cart = (Map<Integer, Integer>) session.getAttribute("cart"); if (cart == null) { cart = new HashMap<>(); session.setAttribute("cart", cart); } cart.put(dishId, cart.getOrDefault(dishId, 0) + 1); resp.sendRedirect(req.getContextPath() + "/cart.jsp"); } }

下单逻辑相对复杂一些，在事务里完成三步：生成订单主记录（订单号、总金额、状态），遍历购物车逐条插入订单明细表，清空Session购物车。三步必须在一个数据库事务里执行，否则会出现订单生成了但明细丢掉一半的脏数据。

事务代码参考：

Connection conn = null; try { conn = DBUtil.getConnection(); conn.setAutoCommit(false); // 1. 插入订单主表 // 2. 循环插入订单明细 // 3. 更新销量 conn.commit(); } catch (Exception e) { if (conn != null) conn.rollback(); throw e; } finally { DBUtil.close(conn); }

这一步是答辨中非常高频的考点，老师一般会问“你怎么保证订单和明细的一致性”，你只要能说清楚setAutoCommit(false)、commit、rollback这三件事，基本就稳了。

4.3 菜品管理与文件上传

管理端的菜品管理就是标准的花式增删改查加一个文件上传。菜品信息包括名称、价格、分类、描述、图片，其中图片上传是最容易出问题的环节，因为涉及操作系统文件路径、Tomcat部署路径、浏览器访问URL三个不同的路径体系，初学者常在这里卡半天。

简单的做法是：项目在开发时设置一个uploads目录作为图片存储目录，比如放在webapp/uploads/下面；上传时通过Part接口获取文件内容，把文件名处理成时间戳加随机数的新名字，避免中文名和重名导致乱码和覆盖；然后把图片写入项目的上传目录，数据库里只存相对路径uploads/xxx.jpg。页面显示图片时，直接用<img src="<%=request.getContextPath()%>/<%=dish.getImage()%>">拼接项目路径访问。

这里有一个重要坑：如果你用IDEA内置的Tomcat跑项目，上传文件写到webapp/uploads/下面后，IDEA往往不会自动把新文件同步到Tomcat的部署副本里，导致页面显示不了图片。解决办法是在Tomcat的server.xml里配一个虚拟映射，或者直接使用外部配置的图片绝对路径，比如在项目里写一个常量UPLOAD_DIR = "D:/upload/"，然后<img>路径通过一个ImageServlet从绝对路径读取文件流输出到浏览器。后一种方案虽然多写一个Servlet，但开发和部署都不容易出问题，我推荐毕设直接采用这个方案。

图片读取Servlet的核心逻辑很简单：

@WebServlet("/image") public class ImageServlet extends HttpServlet { @Override protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws IOException { String name = req.getParameter("name"); File file = new File("D:/upload/" + name); // 校验文件存在、设置ContentType、通过IO流写回 resp.setContentType("image/jpeg"); FileInputStream in = new FileInputStream(file); OutputStream out = resp.getOutputStream(); byte[] buffer = new byte[1024]; int len; while ((len = in.read(buffer)) != -1) { out.write(buffer, 0, len); } in.close(); } }

菜品上下架和删除的逻辑也不复杂，但删除菜品时要想清楚一件事：订单明细表里还可能引用这个菜品的id，所以我前面才强调订单明细里冗余了dish_name和price快照，这样哪怕菜品被删除，历史订单依然能正常展示。做删除操作时，密码学上有句老话叫“先想好后路”，代码上就是先把“删除菜品对历史数据的影响”想清楚再动手。

5. 开发环境配置与部署运行

5.1 环境准备

做JSP项目，开发环境其实非常固定：JDK 8或者11、Tomcat 8.5或9、MySQL 5.7或8.0、IDEA（或者Eclipse）。不要一上来就装JDK 17或者Tomcat 10，Tomcat 10之后把javax.servlet包名改成了jakarta.servlet，市面上大量老教程和网上代码都是javax开头，装了Tomcat 10你会发现导入的Servlet类一路飘红，排查半天最后发现是规范包名变了，非常耽误时间。

环境变量配置也是新手高频卡点。JAVA_HOME指向JDK安装目录，Path里加上%JAVA_HOME%\bin，这两个配置好之后在命令行里输入java -version能正常输出版本号就说明配置成功。注意Win11系统里有时候环境变量改了但命令行没生效，重新打开终端窗口即可。还有一点容易忽略：Tomcat运行也需要JAVA_HOME，如果Tomcat启动一闪而过，去Tomcat/bin目录下看catalina.log日志，大部分原因都是JAVA_HOME没配对或者端口被占。

数据库连接建议直接用MySQL，不要用可视化工具自带的嵌入式库。新建数据库时注意字符集统一用utf8mb4，建库语句：

CREATE DATABASE restaurant DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

utf8mb4比utf8多覆盖了生僻字和Emoji字符，如果你的菜品简介或者用户备注里出现特殊符号，用utf8可能存不进去。

5.2 打包部署到Tomcat

毕业设计最终交付时，一般有两种运行方式：一种是把项目打包成WAR文件放到Tomcat的webapps目录下运行，另一种是直接用IDEA配置Tomcat启动。答辩展示时用IDEA跑没问题，但论文里的部署说明建议写WAR包部署的方式，更正规也更贴近真实项目交付。

打包WAR在IDEA里操作很简单：项目右键 → Open Module Settings → Artifacts → 添加Web Application Exploded/Archive，Build之后在out/artifacts/目录下就能找到WAR文件。把这个WAR文件拷贝到Tomcat的webapps目录下，启动Tomcat，它就会自动解压部署。访问路径是http://localhost:8080/项目名/，如果你的WAR文件名是restaurant.war，那么访问地址就是http://localhost:8080/restaurant/index.jsp。

这里有个部署细节要特别提醒：如果你在数据库连接工具类里把JDBC的url写成了jdbc:mysql://localhost:3306/restaurant?useSSL=false&characterEncoding=utf8，部署到服务器或者换电脑运行时要确认MySQL端口没改、数据库名对得上、数据库服务已经启动。很多同学在自己电脑上跑得好好的，换到答辩电脑上就报Communications link failure，八成是MySQL服务没启动或者host写成固定IP了。

还有一个热词叫“nginx支持jsp吗”，估计很多同学会搜到。这里顺带说明白：Nginx本身不支持解析JSP，它只是一个静态Web服务器和反向代理服务器，遇到JSP文件会把它当作静态文件直接返回或者转发给上游Tomcat处理。标准的部署架构是Nginx监听80端口，把动态请求转发给Tomcat的8080端口，由Tomcat里的JSP引擎负责解析。毕设阶段不需要搞Nginx，但答辩时如果老师问到部署架构，你知道这层关系会显得你知识面比较完整。

6. 常见问题与排查技巧

6.1 数据库连接失败与字符集乱码

数据库连接问题占毕设调试时间的百分之四十以上。最常见的报错是java.sql.SQLException: Access denied for user 'root'@'localhost'，这说明用户名或密码不对，去检查DBUtil里的连接字符串。另一个高发问题是Unknown database 'restaurant'，说明数据库没创建或者名字写错了。最隐蔽的问题是时区报错，MySQL 8.0的驱动对时区校验比较严格，连接串里最好显式加上serverTimezone=Asia/Shanghai，否则会报The server time zone value 'Öйú±ê׼ʱ¼ä'这样的乱码时区错误，看着吓人，其实就是时区没指定。

字符集乱码是JSP项目另一大经典问题。整体策略是“四步统一”：数据库连接串指定characterEncoding=utf8，JSP页面顶部写<%@ page contentType="text/html;charset=UTF-8" language="java" %>，提交表单时页面编码为UTF-8，Servlet里接收参数前执行request.setCharacterEncoding("UTF-8")。四条都做到，基本不会乱码。如果你用的是高版本Tomcat，get请求的参数编码默认是UTF-8，但为了稳妥，最好在Servlet里统一处理一下。

6.2 页面404和静态资源加载不出来

404错误要先分清是Servlet返回的404还是Tomcat默认的404。访问/admin/index.jsp直接404，多半是文件路径不对，看WEB-INF目录里文件是否真的存在。注意WEB-INF下面的页面是不能直接通过浏览器地址栏访问的，只能通过Servletforward转发过去，很多新手把管理页面放在WEB-INF/admin/下面，然后直接访问路径，结果404，然后怎么查都查不出来，这个坑要提前避开。

静态资源加载不出来最常见的原因是路径少写了request.getContextPath()。在JSP页面里引用CSS、JS、图片时，一定不要写死成/css/style.css，而是写成<%=request.getContextPath()%>/css/style.css。因为你打成的WAR包如果部署在tomcat的restaurant上下文路径下，不加项目名前缀，浏览器请求的是http://localhost:8080/css/style.css，当然找不到。这个坑几乎每个做JSP项目的人都会踩一次。

6.3 Tomcat端口冲突与内存溢出

端口冲突是启动阶段最常见的问题。Tomcat默认8080端口，如果你之前启动过实例没关干净，再启动就会报Port 8080 was already in use。排查命令在Windows下是netstat -ano | findstr 8080，看到占用进程的PID后在任务管理器里结束它。如果这个方法不管用，也可以直接修改Tomcat的server.xml把端口改成8081，但不推荐，因为所有代码和文档里涉及URL的地方都要跟着改。

Tomcat内存溢出在毕设阶段一般不会太严重，但如果菜品图片加载特别多或者查询数据量较大，偶尔会报java.lang.OutOfMemoryError: PermGen space（JDK 8以下）或Java heap space。解决办法是在IDEA的Tomcat配置页面的VM options里加上-Xms256m -Xmx512m。不要盲目把内存调得特别大，毕设项目256到512兆完全够了，关键是能说清楚这个参数的用途。

除了上面这些，还有一个特别容易忽略的问题：Java源文件和JSP页面的编译缓存。有时候改了Java代码但运行效果没变，八成是Tomcat没重新部署或者浏览器缓存了旧页面。IDEA里必须让Artifacts设置为“Incremental build”并勾选“Build on frame deactivation”，修改代码后IDEA自动编译重新部署，省去手动重启Tomcat的麻烦。浏览器方面，开发阶段建议直接开启“禁用缓存”模式，用Chrome DevTools的Network面板勾选Disable cache。

7. 性能与安全细节优化

7.1 参数校验与SQL注入防范

答辩老师也是阅卷老师，他们喜欢看到你在项目里体现了安全思维。JSP项目最容易暴露的安全问题就是SQL注入和XSS。SQL注入的根本原因是把用户输入直接拼接进SQL语句。比如登录查询写成"SELECT * FROM t_user WHERE username='" + username + "'"，那么输入'or'1'='1就可能绕过密码校验。防范方式很简单，所有数据库操作都用PreparedStatement，用占位符传参数，不要用Statement拼字符串。

参数校验也要做好，包括前端校验和后端校验两层。前端JS校验只是为了用户体验，后端Servlet里一定要对参数做二次校验。比如下单接口，要校验购物车是否为空、菜品数量是否为正整数、总金额计算是否由后端完成而不是信任前端传过来的金额。曾经有个学生图省事，把总金额直接拿前端隐藏字段传过来的值存库，结果被老师指出后整段重写，答辩时非常被动。

7.2 数据统计与报表展示

订单统计是提升系统含金量的一个很好的切入点。你可以写一个统计SQL，按天统计营业额和订单数。比如后台首页的“今日营业额”，SQL大致是：

SELECT IFNULL(SUM(total_amount), 0) FROM t_order WHERE status IN (1, 2) AND DATE(create_time) = CURDATE();

统计销售额时注意一个细节：是只算已完成订单还是包含已接单的，这个口径要在文档里写清楚。菜品销量的统计可以按菜品id分组从t_order_item里聚合：

SELECT dish_name, SUM(quantity) AS total_sales FROM t_order_item GROUP BY dish_id ORDER BY total_sales DESC LIMIT 10;

把结果展示在后台首页做一个“热销菜品TOP5”排行榜，既好看又不复杂。答辩演示时，先展示首页统计数字，再打开订单管理现场改一条订单状态，回到首页让数字变化，这种“系统动了”的演示方式比干讲代码有说服力得多。

8. 毕设文档与答辩准备

8.1 论文结构怎么组织

代码做完只算完成一半，论文才是最终得分的关键。一般学校要求论文包含摘要、绪论、需求分析、系统设计、系统实现、系统测试、总结展望这几个章节。写论文时一定要注意：系统设计章节要放ER图和用例图，系统实现章节不要大段贴页面代码截图，而是要“先讲思路、再放关键代码、最后说结果”。你贴十页的JSP页面代码不会加分，但如果你能写清楚“购物车为什么放在Session而不建表”，然后配一段购物车核心类代码，老师会觉得你真的理解了设计取舍。

数据库设计章节尤其要写得细：每一张表的字段、类型、含义、约束都要列出来，核心表之间的关系用ER图表达清楚。答辩老师不太可能现场运行你的系统，他们大多是翻论文看表设计是否合理、代码逻辑是否严谨、测试数据是否完整。所以论文里的测试部分不要糊弄，至少写10个以上测试用例，每个用例包含输入、操作步骤、预期结果、实际结果、结论，这是凑字数又显功夫的好地方。

8.2 答辩高频问题与回答方向

JSP+Java毕设的答辩问题其实高度重复，提前准备以下几条基本能扛住大半：

第一，“你的项目里Servlet和JSP谁负责什么？”回答要点是：Servlet负责接收请求、调用JavaBean处理业务逻辑、控制页面跳转；JSP负责展示数据，尽量减少Java代码直接写在页面里。如果你用了EL表达式和JSTL标签库，这会成为一个加分点，可以说“我用EL和JSTL替代了页面里的Java脚本片段”。

第二，“购物车为什么放在Session而不是Cookie？”回答要点是：Session在服务器端保存，可以存对象、容量更大、安全性更好；Cookie最多只能存几KB而且只能存字符串，还得考虑网络传输开销。但要注意Session依赖浏览器Cookie保存JSESSIONID，如果用户禁用了Cookie，可以用URL重写，这里能深讲一层就更好了。

第三，“订单表和订单明细表为什么要分开？”回答要点是：从数据库规范化的角度，订单主表存的是订单整体信息（谁买的、多少钱、什么状态），明细表存的是具体买了哪些菜、各多少份、各多少钱。如果不拆，一个订单买十个菜就会在订单表里存十行，大量重复信息冗余，而且按订单粒度更新状态会非常别扭。拆开之后，订单主表一行就是一个订单，明细表多行描述它的内容，这是一对多的典型建模。

还有老师喜欢问JSP九大内置对象、Session和Cookie的关系、Filter能干什么、事务的ACID特性。这些问题都不难，但一定要自己组织语言提前演练几遍，现场想很容易结巴。

9. 项目后续扩展方向

毕设验收完后，这个项目并不是死胡同。如果你有精力，可以把它朝“前后端分离”方向演进：后端保持Java逻辑，把Servlet替换成Spring Boot的Controller，前端用Vue写一个点餐界面，页面通过AJAX调接口，接口返回JSON数据。这样你就等于把一个传统JSP项目升级成了一套现代Web项目，面试时聊起这个项目也更有底气。

另外一个可以尝试的方向是把系统接上Stripe或者支付宝的沙箱支付，做一个模拟在线支付的回调流程。支付回调的处理涉及签名校验、幂等处理、订单状态变更，这些内容非常贴合真实业务，写到简历上比“我做了增删改查”有吸引力得多。当然这是加分项，核心前提还是先把现有的点餐闭环做稳、做明白。

我自己每年都要看不少学生的毕设代码，最大的感受是：能拿到优秀成绩的往往不是功能最多的那个，而是每个细节都能讲清楚、每个设计决策都有理由的那个。餐厅点餐系统是一个非常成熟的题目，它考察的不是你能不能发明新东西，而是你能不能把一件普通的事情按规范、有逻辑地完成。对你来说，把这篇里的思路、表结构、代码逻辑、部署流程吃透，比到处找一份“完整源码”下载下来改个名字交上去，要有价值得多。源码能帮你过查重，但帮不了你过答辩，更帮不了你应付毕业之后的工作面试。动手写起来吧，卡住了再回头翻这一篇。