简介：面向Java毕业设计场景的社区共享食堂信息系统，基于SSM框架与JSP技术构建，采用MySQL数据库和B/S模式，适合需要完整项目参考的计算机专业学生、课程设计者及Java进阶学习者。压缩包约87.22MB，内含项目源码、数据库脚本、毕业论文、答辩PPT、环境工具包以及相同框架项目的安装教程，覆盖从环境配置到二次开发的关键资料。已有48人学习。系统功能模块包括主页、个人中心、用户管理、美食分类管理、食堂管理、菜品信息管理、系统管理和订单管理等，后台采用SSM框架，前台使用JSP页面，开发工具支持Eclipse、MyEclipse、STS及IDEA，运行环境为JDK1.8，整体按用户、美食、食堂、菜品、订单等维度组织业务。配套论文和答辩PPT可辅助梳理设计思路，安装教程则针对常见部署问题给出排错指导，整体结构清晰，能帮助毕业设计者快速上手项目并理解完整业务逻辑。

1. 毕业设计选它不亏：Java 社区共享食堂系统到底在做什么

毕业设计选什么题，是每年 Java 方向学生最纠结的一件事。java 社区共享食堂信息系统这个题目，本质上是一个标准的 SSM + JSP Web 工程：Spring 管业务对象，SpringMVC 管请求路由，MyBatis 管数据库访问，JSP 渲染页面。它覆盖了 Java Web 开发从建表到部署的完整链路，难度中等，资料齐全，适合想用一套完整系统应付开题、设计和答辩的人。这个题目的核心价值不在“共享食堂”这个业务本身，而在于它同时踩中了登录权限、商品管理、下单流程、文件上传这些 Java Web 的经典考点，每一块都能在论文里写清楚，答辩时也问不倒。

2. 把业务拆成表：共享食堂的数据模型与三张核心表

数据库设计是这种系统最先要做、也最能看出有没有真实项目经验的部分。多数人会先画 ER 图，但真正动手建表时才发现，表之间怎么关联、字段要不要冗余、状态用什么类型，都是需要提前拍板的事。一个社区共享食堂系统，核心业务链路是用户选菜品、下单、食堂配餐或自取、用户评论，围绕这条链路，至少需要用户、菜品、订单、订单明细、评论、公告六张表。

2.1 用户、菜品与公告：先把基础数据立起来

用户表和菜品表是系统的地基。用户表要区分管理员和普通用户，一般用 role 字段，0 是管理员，1 是社区用户，这样登录后的菜单和操作权限就能按角色区分。菜品表要注意“共享”这个业务点，菜品不只属于食堂，也可以由社区用户发起共享，所以加一个 provider 字段记录提供者，比单纯做食堂菜品更能体现题目里的“共享”二字。

CREATE TABLE tb_user ( user_id INT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL UNIQUE, password VARCHAR(64) NOT NULL, real_name VARCHAR(50), phone VARCHAR(20), role TINYINT DEFAULT 1 COMMENT '0-管理员 1-社区用户', status TINYINT DEFAULT 1 COMMENT '1-正常 0-禁用', create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE tb_dish ( dish_id INT PRIMARY KEY AUTO_INCREMENT, dish_name VARCHAR(100) NOT NULL, category VARCHAR(50) COMMENT '分类：热菜/凉菜/主食/汤品', price DECIMAL(10,2) NOT NULL, stock INT DEFAULT 0 COMMENT '每日供应量', sales INT DEFAULT 0 COMMENT '销量，排序用', image VARCHAR(255) COMMENT '菜品图片访问路径', provider VARCHAR(50) COMMENT '提供者，共享场景下记录来源', status TINYINT DEFAULT 1 COMMENT '1-上架 0-下架', create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE tb_notice ( notice_id INT PRIMARY KEY AUTO_INCREMENT, title VARCHAR(100) NOT NULL, content TEXT, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

密码字段用 VARCHAR(64) 是为了兼容 MD5 或 SHA-256 的散列结果。用 DECIMAL(10,2) 存价格而不是 FLOAT，是因为浮点数在金额计算上会出精度问题，答辩时这也是一个可以说的设计点。菜品表加 sales 字段做销量统计，可以避免每次排序都去订单明细表里做聚合，属于典型的空间换时间。

2.2 订单与订单明细：共享食堂的业务主链路

订单表和订单明细表是这种系统里最重要的两张表，也是区分“会不会设计”的分水岭。订单主表只存一次下单的汇总信息，包括总金额、状态、下单人、下单时间；明细表存每个菜品买了多少份、当时的价格。为什么要单独拆明细表？因为一个订单可能包含多个菜品，如果只在一张表里用一个字段存“鱼香肉丝 x2、米饭 x1”，后续统计销量、写评论、做报表全都没法查。

CREATE TABLE tb_order ( order_id INT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL UNIQUE COMMENT '订单编号，前端展示用', user_id INT NOT NULL, total_price DECIMAL(10,2) NOT NULL, status TINYINT DEFAULT 0 COMMENT '0-待支付 1-已支付 2-已完成 3-已取消', meal_time VARCHAR(20) COMMENT '用餐时段：午餐/晚餐', create_time DATETIME DEFAULT CURRENT_TIMESTAMP, pay_time DATETIME, CONSTRAINT fk_order_user FOREIGN KEY (user_id) REFERENCES tb_user(user_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE tb_order_item ( item_id INT PRIMARY KEY AUTO_INCREMENT, order_id INT NOT NULL, dish_id INT NOT NULL, dish_name VARCHAR(100) COMMENT '冗余菜品名称，防止菜品改名后历史订单失真', price DECIMAL(10,2) COMMENT '下单时的单价快照', quantity INT NOT NULL DEFAULT 1, CONSTRAINT fk_item_order FOREIGN KEY (order_id) REFERENCES tb_order(order_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

order_no 用 VARCHAR(32) 存业务单号，不用自增主键做展示，是因为订单号通常要包含日期和随机位，比如 202506011430001234，方便按天检索。明细表里冗余 dish_name 和 price 是刻意的，菜品改价或改名后，历史订单里的记录不能跟着变，这就是“快照”的含义。外键在毕业设计里建议保留，虽然性能上有争议，但论文里写“通过外键保证数据完整性”是加分项。

2.3 评论与时段字段：毕业设计里最容易加分的两处设计

评论表连接到订单而不是直接连接菜品，这样做可以让一条评论对应一个订单里的所有菜品，也可以按订单维度去重，防止同一个用户对同一道菜刷评论。如果只做“菜品评论”，评论表直接关联 dish_id 就可以，但关联 order_id 能够顺带校验“这个人确实买过”，逻辑更完整，答辩时也更经得起追问。

共享食堂和普通食堂的差别在“时段”和“共享”两个词上。tb_order 里加 meal_time 字段，区分午餐和晚餐；tb_dish 里加 provider 字段，记录是哪位社区居民共享出来的菜。这两个字段不需要额外建表，但有了它们，题目里的“共享”就有了落脚点。评论表结构不复杂，三个字段就够用：评分、内容、创建时间。把这几张表建好后，系统的数据骨架就算立住了。

3. SSM 三件套的落地配置：跑通一个请求要经过哪些文件

SSM 是 Spring、SpringMVC、MyBatis 三个框架的组合，也是 Java Web 毕业设计里最常见的技术栈。现在新项目更喜欢 Spring Boot + MyBatis 的极简配置，但毕业设计用 SSM 的仍然非常多，原因很简单：Spring Boot 把配置都帮你藏起来了，论文里没有东西可写，答辩时老师一问配置细节就容易露怯。SSM 则把每个配置都摆在明面上，数据源、事务、拦截器、视图解析器，每个文件都能讲出作用，这就是它的价值。

3.1 三件套的职责边界：从一次请求的旅程说起

一次请求从浏览器发出来，先被 DispatcherServlet 接住，SpringMVC 根据 @RequestMapping 找到对应的 Controller 方法；Controller 调用 Service 接口，Service 实现类里写业务逻辑；Service 需要查询数据库时，调用 Mapper 接口，MyBatis 把 Mapper 接口和 XML 里的 SQL 绑定起来，执行后返回对象；最后 Controller 把数据塞进 ModelAndView，JSP 负责渲染成 HTML 返回浏览器。Spring 自始至终在做同一件事：管理这些对象的创建和依赖关系，让 Controller、Service、Mapper 之间的引用通过容器注入，而不是到处 new。

理解这个流程之后，配置文件的职责就清楚了。web.xml 是整个 Web 应用的入口，负责启动 Spring 容器和配置 SpringMVC 的前端控制器；applicationContext.xml 承载 Spring 的全局配置，重点是数据源和事务；spring-mvc.xml 只管 Controller 层的组件扫描、注解驱动和视图解析器；mybatis-config.xml 配置 MyBatis 的全局行为。四个文件各管一摊，少一个都跑不起来。

3.2 applicationContext.xml：数据源、事务与 Mapper 扫描

数据源是 SSM 配置里最先要搞定的事。常用的方案有 Druid、C3P0，也有直接用 Spring 自带 DriverManagerDataSource 的。毕业设计用 Druid 比较合适，因为它的监控页面在答辩时能展示“连接池状态”这种亮点。数据源配好之后，接下来是 SqlSessionFactoryBean 和 MapperScannerConfigurer，前者把 MyBatis 集成进 Spring，后者把 Mapper 接口所在的包整体扫描注册成 Bean，省去一个个写的麻烦。

<!-- applicationContext.xml 核心配置片段 --> <context:component-scan base-package="com.canteen.service"/> <bean id="dataSource" class="com.alibaba.druid.pool.DruidDataSource"> <property name="driverClassName" value="com.mysql.cj.jdbc.Driver"/> <property name="url" value="jdbc:mysql://localhost:3306/canteen?useSSL=false&amp;serverTimezone=Asia/Shanghai"/> <property name="username" value="root"/> <property name="password" value="123456"/> </bean> <bean id="sqlSessionFactory" class="org.mybatis.spring.SqlSessionFactoryBean"> <property name="dataSource" ref="dataSource"/> <property name="configLocation" value="classpath:mybatis-config.xml"/> <property name="mapperLocations" value="classpath:mapper/*.xml"/> </bean> <bean class="org.mybatis.spring.mapper.MapperScannerConfigurer"> <property name="basePackage" value="com.canteen.mapper"/> </bean> <bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager"> <property name="dataSource" ref="dataSource"/> </bean> <tx:annotation-driven transaction-manager="transactionManager"/>

driverClassName 用的是 com.mysql.cj.jdbc.Driver，这是 MySQL 8 的驱动类名，MySQL 5.x 是 com.mysql.jdbc.Driver，混用会直接抛 ClassNotFoundException。url 里的 serverTimezone=Asia/Shanghai 必须加，MySQL 8 驱动要求显式指定时区，漏掉这个参数启动时就报错。mapperLocations 指向 XML 文件的位置，basePackage 指向 Mapper 接口的包，两者的包路径和接口名要对应上，否则 MyBatis 会报 binding exception。

3.3 spring-mvc.xml 与常用注解：Controller 层的工作方式

spring-mvc.xml 的配置比 applicationContext.xml 少很多，但有一个容易漏的点：组件扫描的范围。如果 spring-mvc.xml 里扫描整个 base-package，会把 Service 层的 Bean 也扫进来，导致事务相关的问题；常见做法是只扫描 controller 包，让 Service 层的扫描交给 applicationContext.xml 处理。视图解析器也在这里配置，InternalResourceViewResolver 是 JSP 场景的标准选择，prefix 和 suffix 决定了 Controller 返回的字符串对应哪个 JSP 文件。

<!-- spring-mvc.xml --> <context:component-scan base-package="com.canteen.controller"/> <mvc:annotation-driven/> <bean class="org.springframework.web.servlet.view.InternalResourceViewResolver"> <property name="prefix" value="/WEB-INF/jsp/"/> <property name="suffix" value=".jsp"/> </bean> <mvc:resources mapping="/static/**" location="/static/"/>

Controller 层最常用的几个注解是 @Controller、@RequestMapping、@ResponseBody，配合 Service 层的 @Service 和 @Autowired 使用。@RequestMapping 可以写在类上也可以写在方法上，类上写的是模块前缀，方法上写的是具体路径，比如类上写 /dish，方法上写 /list，前端访问就是这个配置的完整拼接。@ResponseBody 用于返回 JSON 数据，适合做 Ajax 接口，普通页面跳转不需要加这个注解。Service 层做数据库写操作时，在方法上加 @Transactional 可以保证一个方法里的多条 SQL 要么全成功要么全回滚，这是答辩时一定会被问到的高级点。

3.4 PageHelper 分页：条件查询的三行代码

菜品列表和订单列表都要做分页，否则数据量一大页面就卡。PageHelper 是一个 MyBatis 的分页插件，用法很简单，但踩过坑的人都知道它有个重要特性：PageHelper.startPage 只对紧接着的下一条查询语句生效。如果 startPage 之后先执行了别的查询，分页就错位了，这是最常见的翻车现场。

@Controller @RequestMapping("/dish") public class DishController { @Autowired private DishService dishService; @RequestMapping("/list") public String list(String keyword, @RequestParam(defaultValue = "1") Integer pageNum, Model model) { PageHelper.startPage(pageNum, 8); List<Dish> dishList = dishService.selectByKeyword(keyword); PageInfo<Dish> pageInfo = new PageInfo<>(dishList); model.addAttribute("pageInfo", pageInfo); return "dish/list"; } }

PageHelper.startPage 的第一个参数是页码，从 1 开始，第二个参数是每页条数。PageInfo 里封装了总条数、总页数、当前页等分页信息，前端 JSP 用 EL 表达式就能渲染出翻页按钮。注意一个细节：selectByKeyword 里的 SQL 不能自己写 LIMIT，PageHelper 会在执行时自动拼接 LIMIT 语句，自己写反而会冲突。排序也可以用 PageHelper 的 orderBy 方法，或者直接用 Java 排序比较器在内存里排，数据量不大时后者更简单。

4. JSP 页面与数据流转：用户看到的前端是怎么拼出来的

JSP 是这套系统的表现层，也是很多人觉得烦的部分。实际上 JSP 的定位很明确：它本质上是 HTML 模板，里面嵌入 Java 代码或者 JSTL 标签，用来把后端传来的数据渲染到页面上。毕业设计里的 JSP 页面通常放在 WEB-INF/jsp 目录下，这样的好处是用户不能通过浏览器直接访问 JSP 文件，必须经过 Controller 转发才能看到页面，权限控制更安全。

4.1 登录拦截与 Session：权限控制的第一道门

登录功能谁都会写，难点在于“没登录就不能访问页面”这个拦截逻辑。常见做法是写一个 HandlerInterceptor，在请求进入 Controller 之前检查 Session 里有没有登录用户。如果没登录，直接重定向到登录页；如果登录了但访问的是管理员页面，还要再校验角色。这样比在每个 Controller 方法里手动判断要省事得多，也显得代码有设计感。

public class LoginInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { Object user = request.getSession().getAttribute("loginUser"); if (user == null) { response.sendRedirect(request.getContextPath() + "/login"); return false; } return true; } }

<!-- spring-mvc.xml 中注册拦截器 --> <mvc:interceptors> <mvc:interceptor> <mvc:mapping path="/**"/> <mvc:exclude-mapping path="/login"/> <mvc:exclude-mapping path="/static/**"/> </mvc:interceptor> </mvc:interceptors>

拦截器的核心是 preHandle 方法返回 false 时请求被拦截，不再往下走。mvc:mapping 的 /** 表示拦截所有请求，exclude-mapping 把登录页和静态资源排除在外，否则 CSS 和 JS 也进不来拦截器，但页面样式加载不出来。登录成功后需要把用户对象放进 Session，键名和拦截器里取的键名必须一致，loginUser 两处写一样。退出登录就是调用 session.invalidate() 清空 Session，再重定向到登录页。

4.2 EL 表达式与 JSTL：列表页怎么把数据渲染出来

JSP 页面里最常用的就是 EL 表达式配合 JSTL 的 c:forEach 标签。Controller 把 List 塞进 Model 之后，JSP 里用 c:forEach 循环取出每条数据渲染成表格或卡片。EL 表达式用 ${} 语法取值，比如 ${dish.dishName} 等价于调用 Dish 对象的 getDishName() 方法。取值取不出来的时候，先检查 JavaBean 有没有对应的 getter 方法——这是新手最容易忽略的地方。

<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %> <%@ taglib prefix="fmt" uri="http://java.sun.com/jsp/jstl/fmt" %> <table class="table"> <tr> <th>菜品名称</th> <th>分类</th> <th>价格</th> <th>销量</th> <th>状态</th> </tr> <c:forEach items="${pageInfo.list}" var="dish"> <tr> <td>${dish.dishName}</td> <td>${dish.category}</td> <td><fmt:formatNumber value="${dish.price}" pattern="0.00"/></td> <td>${dish.sales}</td> <td> <c:if test="${dish.status == 1}">上架</c:if> <c:if test="${dish.status == 0}">下架</c:if> </td> </tr> </c:forEach> </table>

页面顶部必须引入 JSTL 的 taglib 指令，否则 c:forEach、c:if 这些标签会被当成普通文本输出，页面上一堆乱码一样的标签内容。fmt:formatNumber 用来格式化价格，避免出现 12.5 这种不够整齐的显示。c:if 的 test 属性里写的是 EL 表达式，注意 dish.status == 1 这里的 1 不用加引号，因为 JSP 页面拿到的是 Integer 类型。页面能正确显示数据的前提，是 Controller 里 model.addAttribute 的键名和 JSP 里 items 的取值键名一致。

4.3 图片上传：菜品图片的存取路径问题

菜品图片是这类系统里比较麻烦的一块。上传本身不难，难的是路径和回显。如果图片直接存进数据库的 BLOB 字段，数据库会变得臃肿，查询也慢；常见做法是把图片保存到服务器本地磁盘，数据库里只存图片的访问路径。上传接口用 CommonsMultipartResolver 解析 multipart 请求，保存文件时文件名用时间戳加随机数拼接，防止重名覆盖。

@RequestMapping("/upload") @ResponseBody public String upload(@RequestParam("file") MultipartFile file, HttpServletRequest request) { if (file.isEmpty()) { return "请选择文件"; } String originalFilename = file.getOriginalFilename(); String ext = originalFilename.substring(originalFilename.lastIndexOf(".")); String fileName = System.currentTimeMillis() + "_" + new Random().nextInt(1000) + ext; String realPath = request.getServletContext().getRealPath("/static/upload"); File dir = new File(realPath); if (!dir.exists()) { dir.mkdirs(); } try { file.transferTo(new File(dir, fileName)); return "/static/upload/" + fileName; } catch (IOException e) { e.printStackTrace(); return "上传失败"; } }

上传接口返回的是图片的相对路径，前端把这个路径存到菜品表里的 image 字段。回显时，img 标签的 src 属性直接用这个路径就可以，因为 spring-mvc.xml 里已经配置了 /static/** 映射到磁盘目录。有一个坑是 getRealPath 拿到的目录在 Tomcat 重启后可能被清理，尤其是用 IDEA 内置 Tomcat 时，所以真正部署时一般把上传目录放到服务器固定路径，再用 mvc:resources 映射到外部目录。文件大小限制也要在 spring-mvc.xml 里配，默认 1MB 可能不够用。

5. 避坑指南：从“跑不起来”到“能演示”的 5 个排查点

SSM 项目跑不起来的时候，报错信息往往千奇百怪，但只要按层级排查，大多数问题都能在上手十分钟内找到根源。这一章的内容是从“环境变量没配好”到“页面数据全是 null”的真实踩坑记录，每一条都是我自己做过或帮别人排查过的。

5.1 数据库连不上：八成是驱动版本问题

现象是启动 Tomcat 时报 ClassNotFoundException: com.mysql.jdbc.Driver，或者报 Communications link failure。原因是 pom 里引入的 mysql-connector-java 版本和配置里的驱动类名对不上。MySQL 5.x 系列用 com.mysql.jdbc.Driver，MySQL 8 以后改成了 com.mysql.cj.jdbc.Driver。解决方法是统一版本：MySQL 8 就引入 8.x 驱动并在配置里写 com.mysql.cj.jdbc.Driver，url 里加 serverTimezone=Asia/Shanghai；MySQL 5.x 就继续用老驱动类名。这类问题看连接异常的第一行就能定位，ClassNotFoundException 对应驱动类缺失，Communications link failure 对应地址、端口或时区参数错误。

5.2 中文全乱码：三处编码要一起对齐

现象是页面显示中文全是问号，或者数据库里存的中文读出来是乱码。原因是 JSP 页面编码、Tomcat 请求编码、数据库连接编码三处没有统一。解决方法是三处都设为 UTF-8：JSP 文件第一行写 pageEncoding="UTF-8"，web.xml 里配置 CharacterEncodingFilter 强制请求和响应都用 UTF-8，数据库连接 url 加 characterEncoding=utf8。MySQL 表本身的字符集也要是 utf8mb4，建表语句里已经指定。漏掉任意一处，问题都可能在某个特定页面才暴露，排查时先看数据库里存的数据是不是正常，再看页面响应头里的 charset。

5.3 CSS/JS 全 404：DispatcherServlet 把静态资源拦了

现象是页面能打开但没有任何样式，按 F12 看 Network，发现所有 .css 和 .js 文件都返回 404。原因是 web.xml 里 DispatcherServlet 的 url-pattern 配成 /，把静态资源请求也拦进了 SpringMVC，而 SpringMVC 默认不处理静态资源。解决方法是 spring-mvc.xml 里加一行 mvc:resources mapping="/static/**" location="/static/"，让静态资源绕过 Controller 直接由容器返回。页面里引用静态资源的路径也要注意，用 ${pageContext.request.contextPath}/static/css/style.css 这种绝对路径，不要写相对路径，否则在二级路由下会找不到文件。

5.4 查出来全是 null：MyBatis 驼峰映射没开

现象是列表页能查询出数据，但页面上每个字段都是空白，后端日志里 SQL 正常执行。原因是数据库字段是下划线命名 user_id，JavaBean 属性是驼峰命名 userId，MyBatis 默认不自动转换。解决方法是 mybatis-config.xml 里开启 mapUnderscoreToCamelCase 设置为 true，或者在 SQL 里给每个字段起别名user_id AS userId。开启驼峰映射是一劳永逸的做法，但要注意：如果项目里同时存在两种命名风格的字段，开启后下划线字段会被自动映射到驼峰属性，可能掩盖掉真正的映射错误，排查时先看 SQL 查出来的列名和 JavaBean 的属性名。

5.5 端口占用与热部署失效：Tomcat 的日常问题

现象是启动时报 Port 8080 was already in use，或者改了 Java 代码后页面不生效，还要手动重启才能看到变化。端口占用的解决方法是换端口或找到占用进程杀掉，Windows 下用 netstat -ano | findstr 8080 找到 PID，再在任务管理器里结束进程。热部署失效通常分两种：一种是 IDEA 里没开启 On Update Action 的 update classes and resources；另一种是改了 spring-mvc.xml 或者 web.xml 这类配置文件，热部署不会重新加载配置文件，必须重启。还有个隐藏很深的坑：JSP 页面修改后浏览器缓存不刷新，按 Ctrl+F5 强制刷新还是旧页面，这时候再看看 Tomcat 的 work 目录下的编译缓存，清掉后重启即可。

6. 答辩前的最后一晚：验证清单与演示话术

系统能跑通只是第一步，答辩时的演示顺序和讲解节奏往往比功能本身更重要。我习惯在答辩前做一次“全流程彩排”：从打开浏览器开始，按照普通用户的路径把核心功能走一遍，再切管理员账号走一遍，全程不碰源码。演示顺序建议是先登录，再浏览菜品列表，加两个菜进购物车，提交订单，支付模拟，查看订单状态，最后写一条评论。走到订单和评论这两步时，主动点开数据库看一眼，把后台数据和页面数据对应上，这个动作比口头解释“数据存进去了”有说服力得多。

提前准备一组像样的演示数据也很有必要。菜品不要只造两三行，价格要合理，品类要覆盖热菜、主食、汤品几类；用户、订单、评论都要有真实感。答辩时最怕的不是功能有 Bug，而是演示时页面空荡荡，老师看不到业务逻辑。如果时间来得及，把订单列表做成按状态筛选，加一个按销量排序的按钮，这两个小功能在演示时非常出彩。

提示：答辩前把数据库导出 SQL 文件放在项目根目录，命名为 canteen.sql。万一现场数据库环境有问题，能快速重建，这是你的后悔药。

关于原理的提问，SSM 的面试题和答辩问题高度重合。老师常问的几个问题要提前准备：SpringMVC 的处理流程是怎样的、MyBatis 里 #{} 和 ${} 的区别、事务的传播行为、拦截器和过滤器的区别。这些问题的答案写两三百字就够了，不用背代码，关键是能用自己的话讲清楚。比如 #{} 是预编译参数占位符，能防止 SQL 注入；${} 是字符串拼接，适合动态表名这种场景，但有注入风险。能答出这个对比，老师就能看出你是真做过还是只抄了代码。

最后说一个我自己的教训：当年答辩前一天，我把项目从本机拷贝到演示机器，没检查 JDK 版本，现场启动时发现 JDK 11 跑不了项目配置的旧版 Tomcat，折腾了十几分钟才调好。后来我养成一个习惯，任何项目演示前，在演示机器上做一次完全干净的部署：数据库重新导入 SQL，Tomcat 重新解压，代码重新编译，全程不依赖 IDE。做一次这种演练，比背十页答辩稿都管用。

这个项目方向我前后带不少人跑通过，大部分时间都花在环境配置而不是业务代码上。拿到资料后先别急着看代码，按章节顺序把环境搭起来，再对照数据库脚本理解表结构，最后改几个自己想要的页面，这样才能真的把它变成你自己的东西。希望帮到你。

本文还有配套的精品资源，点击获取