每年毕业季前后，技术社区里问“毕设做什么”“SSM到底怎么跑起来”的人一下子就多起来了。“ssm+java2026年毕设社区食堂供餐”这个题目标题，实际上代表了一类非常典型的Java毕业设计项目：用SSM框架做一个面向社区食堂的业务管理供餐系统，前端支撑用户点餐、食堂管理员接单，后端按角色划分权限，数据库用MySQL，项目最后附带完整源码和论文。它解决的是一顿社区食堂餐从选菜、下单、接单、制作到结算的完整流程问题。
这类题目的目标读者是三类人：准备毕业设计但还没有定题的计算机相关专业学生，想通过一个完整项目练手SSM框架整合的Java初学者，以及想了解“社区食堂”这类线下餐饮场景如何做系统设计的开发人员。如果你正在找一个“技术不冷门、业务不难懂、工作量还能撑起一篇论文”的毕设题目，这个方向确实值得认真看一遍。下面我把这个项目的设计思路、数据库建设、框架整合流程、论文写作和答辩经验完整拆开讲。
1. 项目定位与整体设计思路拆解
1.1 为什么社区食堂供餐这个选题适合做毕设
先说结论：毕设选题最怕三种情况，一是题目太大做不完，二是题目太小没内容写，三是技术栈太旧或者太偏没人能指导。社区食堂供餐系统恰好避开了这些问题。
从业务角度看，社区食堂的日常运营比普通餐厅简单，但又有完整的业务闭环。食堂要提供菜品，用户要浏览菜谱、下单、支付或到店取餐，食堂后台要处理订单、统计销量、管理菜品上下架，系统管理员还要维护用户状态和基础数据。这个链条刚好覆盖了“增删改查、购物车、订单状态流转、统计报表”这些毕设论文最常要求的核心功能点，不至于像“图书管理系统”那样单调，也不会像“电商平台”那样需要面对复杂的支付网关、物流体系而失控。
从工作量角度看，社区食堂供餐系统做出来之后至少有三种角色、十几个功能页面，天然能把“需求分析、数据库设计、系统实现、系统测试”四块内容都填满。尤其是订单状态从待支付到已完成再到取消的流转过程，写进论文里既有业务深度，又能体现你对系统设计的思考，周老师一看就知道这是认真做的，不是临时拼凑的。
1.2 核心技术选型：SSM组合的底气在哪
SSM指的是Spring、SpringMVC、MyBatis三个框架组合。很多同学会问，现在企业里都用Spring Boot了，为什么毕设还要做SSM？这里面的逻辑其实很简单。
Spring在这个组合里负责对象管理，也就是IoC容器和AOP事务。所有Service层的业务对象交给Spring容器创建和维护，事务边界也通过注解或XML声明式配置来控制，这是理解Java后端开发的基石。SpringMVC负责Web层的请求分发，从前端页面来的HTTP请求由DispatcherServlet统一接收，再路由到对应的Controller方法，返回视图或JSON数据。MyBatis负责数据库操作，把Java实体类和数据库表字段映射起来，通过Mapper接口加XML文件的方式写SQL，灵活可控，也方便展示你对SQL语句的理解能力。
相比直接使用Spring Boot的起步依赖一键生成项目，SSM需要手动配置web.xml、Spring容器、SpringMVC容器、数据源、事务管理器，这个过程本身就是一次极好的框架原理训练。答辩时老师问“DispatcherServlet是怎么找到Controller的”“MyBatis的Mapper接口为什么不用写实现类”，你只要认真配置过一遍就能答上来。如果直接用Spring Boot，这些问题很容易因为“框架太自动”而答不清楚。所以SSM不是技术落后，而是更适合作为教学和毕设项目来夯实基础。
1.3 功能模块划分与角色权限设计
社区食堂供餐系统通常设计三种角色：普通用户、食堂工作人员、系统管理员。用户的日常操作是注册登录、浏览菜品、下单、查看订单状态；食堂工作人员负责菜品上下架、处理订单、统计当日销量；系统管理员负责管理用户账号、查看全系统订单、发布公告等。
我建议在系统设计这章用一张表格把功能矩阵列清楚，论文里好写，代码里也好对齐。
| 角色 | 核心功能 | 对应页面 |
|---|---|---|
| 普通用户 | 注册登录、浏览菜品分类、加入购物车、下单、查看个人订单、修改个人信息 | 菜品列表页、购物车页、订单列表页、个人中心 |
| 食堂工作人员 | 登录、管理菜品分类与菜品、查看并更新订单状态、查看当日经营统计 | 菜品管理页、订单处理页、统计页 |
| 系统管理员 | 管理用户状态、管理公告、查看全系统订单、数据统计与导出 | 用户管理页、公告管理页、订单总览页 |
权限控制在毕设阶段不需要引入Spring Security这种重型框架，用SpringMVC的拦截器就可以实现：在HandlerInterceptor里判断当前登录用户角色，通过session读取用户信息，放行匹配的角色请求，拦截不匹配的请求并跳转到错误页面。只要把需要管理员权限的URL前缀统一收口，比如/admin/**，配置一个拦截器就能解决80%的权限问题。这样的设计也能在论文里写清楚“基于拦截器的轻量级权限控制方案”。
2. 数据库设计与核心表结构实操
2.1 从业务场景推导表结构
数据库设计是整个项目最容易返工的部分。我的建议是别先急着写表，先画一遍业务主线：用户进入食堂小程序或网页，看到按分类展示的菜品，把菜加入购物车，提交订单后生成一条订单记录，订单明细里记录每道菜的份数和单价，食堂在后台看到新订单后修改状态。顺着这条线，核心表就出来了。
我建议至少设计八张表：用户表、菜品分类表、菜品表、购物车表、订单表、订单明细表、公告表、评价表。其中购物车表在毕设里可以简单做，用户每次登录后购物车清空也可以，但表结构要预留；评价表可以根据时间决定是否实现，如果论文需要多一些功能点就加上。
顺着业务推导表结构，而不是从网上找一张大而全的数据库又往里硬套，最大的好处是答辩时老师问“为什么这个表有这个字段”，你都能讲出业务依据。
2.2 核心建表SQL和字段设计原则
直接给一份我实际用过的核心表SQL，你在设计时可以在此基础上改。我统一使用utf8mb4字符集，避免中文和表情符号出现乱码。用户表：
CREATE TABLE `user` ( `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '主键', `username` varchar(50) NOT NULL COMMENT '登录名', `password` varchar(100) NOT NULL COMMENT '密码', `real_name` varchar(50) DEFAULT NULL COMMENT '姓名', `phone` varchar(20) DEFAULT NULL COMMENT '手机号', `role` varchar(20) NOT NULL DEFAULT 'USER' COMMENT '角色 USER/ADMIN/STAFF', `status` tinyint(4) DEFAULT 1 COMMENT '状态 1正常 0禁用', `create_time` datetime DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', PRIMARY KEY (`id`), UNIQUE KEY `uk_username` (`username`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户表';菜品表和订单相关的表：
CREATE TABLE `dish` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `category_id` bigint(20) NOT NULL COMMENT '菜品分类', `name` varchar(50) NOT NULL COMMENT '菜品名', `price` decimal(10,2) NOT NULL COMMENT '价格', `image` varchar(200) DEFAULT NULL COMMENT '图片', `description` varchar(500) DEFAULT NULL COMMENT '描述', `stock` int(11) DEFAULT 100 COMMENT '日库存', `status` tinyint(4) DEFAULT 1 COMMENT '1上架 0下架', `create_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='菜品表'; CREATE TABLE `orders` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `order_no` varchar(32) NOT NULL COMMENT '订单号', `user_id` bigint(20) NOT NULL COMMENT '下单用户', `total_amount` decimal(10,2) NOT NULL COMMENT '总金额', `status` tinyint(4) NOT NULL DEFAULT 1 COMMENT '1待支付 2已支付 3制作中 4待取餐 5已完成 6已取消', `remark` varchar(200) DEFAULT NULL COMMENT '备注', `create_time` datetime DEFAULT CURRENT_TIMESTAMP, `pay_time` datetime DEFAULT NULL, `complete_time` datetime DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='订单表'; CREATE TABLE `order_detail` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `order_id` bigint(20) NOT NULL, `dish_id` bigint(20) NOT NULL, `dish_name` varchar(50) NOT NULL COMMENT '菜品名称快照', `dish_price` decimal(10,2) NOT NULL COMMENT '菜品单份价格快照', `quantity` int(11) NOT NULL COMMENT '数量', `subtotal` decimal(10,2) NOT NULL COMMENT '小计', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='订单明细表';几个字段设计上的注意事项：金额一律用decimal(10,2)，不要用float和double，存金额出现精度误差是很低级的错误。状态字段用tinyint加注释，不要用字符串直接存“待支付”“已支付”，一方面节约空间，另一方面代码里用常量或枚举映射状态，扩展性更好。时间字段统一用datetime，在Java实体类里对应Date类型，配合MyBatis的类型处理器不会有兼容问题。
2.3 订单状态机与数据关联设计
订单表里有一个很关键的设计点，就是状态流转。一个订单从创建到结束，状态顺序是：待支付、已支付、制作中、待取餐、已完成，另外还有已取消。我在项目里把状态值定义成常量类统一管理，Service层修改订单状态时只有通过状态机的判断逻辑才能流转成功，避免出现“已取消的订单突然变成制作中”这种数据混乱。
订单明细里必须冗余保存菜品名称和单价快照。原因很简单：食堂菜品价格可能调整，如果订单明细只存dish_id，用户查到历史订单时价格和名称就会显示成最新的，这对一个订单系统来说是不可接受的。冗余字段牺牲了一点存储，换来了订单历史的稳定，这是最实用也最规范的做法。
订单表和订单明细表使用逻辑外键关系，不在数据库层面强行加外键约束，而是通过Service层的事务来保证一致性。这样做的理由是：高并发插入明细时外键约束会成为性能瓶颈，同时逻辑外键可以避免以后分库分表时还要处理物理外键的麻烦。这个设计理念写到论文里“数据库优化”部分，是个不错的加分点。
3. SSM整合细节与后端核心业务实现
3.1 项目分层结构与包名规范
拿到源码之后，如果一上来就翻代码，很容易被包结构绕晕。SSM项目的分层核心就是Controller、Service、Dao三层，再配上实体类和公共工具包。包结构我强烈建议按技术分层而不是按业务分，这样代码扫一眼就能定位。
com.community.canteen ├── controller // 控制层，接收请求返回页面或JSON │ ├── UserController.java │ ├── DishController.java │ └── OrderController.java ├── service // 业务层接口 │ └── impl // 业务实现 ├── dao // MyBatis的Mapper接口 ├── entity // 数据库实体类 ├── common // 常量、工具类、统一返回结果 ├── config // 拦截器、全局异常处理 └── interceptor // 角色权限拦截器我在做项目时习惯把Controller层的接口返回分成两类：渲染页面的请求返回ModelAndView或字符串，前端通过Ajax异步请求返回JSON。混用时会带来序列化问题，所以我会创建统一的Result实体类，包含code、message、data字段，所有异步接口都返回它，前端JS里统一判断code再做后续操作，这样联调时可以少踩很多坑。
3.2 三个关键配置文件的组装
SSM整合最核心的是三个配置入口：web.xml、Spring配置文件、SpringMVC配置文件。很多人项目跑不起来，问题大部分出在这三个文件的加载顺序和扫描路径上。
web.xml负责配置DispatcherServlet和字符编码过滤器，注意过滤器的映射顺序要在DispatcherServlet之前，否则请求还没处理就乱码了。Spring的配置文件如applicationContext.xml，主要配置数据源、SqlSessionFactory、MyBatis Mapper扫描和事务管理器；SpringMVC的配置文件如spring-mvc.xml，配置Controller组件扫描、注解驱动、视图解析器和静态资源放行。
我给你看一段我常用的Spring配置文件核心内容：
<!-- applicationContext.xml 核心配置 --> <context:component-scan base-package="com.community.canteen"> <context:exclude-filter type="annotation" expression="org.springframework.stereotype.Controller"/> </context:component-scan> <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?useUnicode=true&characterEncoding=utf8&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="mapperLocations" value="classpath:mapper/*.xml"/> </bean> <bean class="org.mybatis.spring.mapper.MapperScannerConfigurer"> <property name="basePackage" value="com.community.canteen.dao"/> </bean> <bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager"> <property name="dataSource" ref="dataSource"/> </bean> <tx:annotation-driven transaction-manager="transactionManager"/>SpringMVC的配置则简单很多，重点是扫描Controller包和配置视图解析器：
<!-- spring-mvc.xml 核心配置 --> <mvc:annotation-driven/> <context:component-scan base-package="com.community.canteen.controller"/> <bean class="org.springframework.web.servlet.view.InternalResourceViewResolver"> <property name="prefix" value="/WEB-INF/views/"/> <property name="suffix" value=".jsp"/> </bean> <mvc:resources mapping="/static/**" location="/static/"/>注意：Spring容器扫描Service、Dao等组件，SpringMVC容器扫描Controller，两者扫描范围一定要分开。如果Spring容器把Controller也扫进去了，会导致事务失效或者请求映射重复。这是我排查过无数遍的经典问题。
3.3 下单业务与订单状态流转的编码实现
下单操作是整个系统的核心业务，也是论文里“系统实现”章节的展示重点。我用一个订单提交方法来演示关键逻辑，代码不复杂，但每一步都有明确目的。
@Transactional public Order createOrder(Long userId, List<CartItem> cartItems, String remark) { // 1. 校验购物车非空 if (cartItems == null || cartItems.isEmpty()) { throw new BusinessException("购物车为空"); } // 2. 遍历购物车，读取菜品真实价格，计算总金额 BigDecimal total = BigDecimal.ZERO; List<OrderDetail> details = new ArrayList<>(); for (CartItem item : cartItems) { Dish dish = dishDao.selectById(item.getDishId()); if (dish == null || dish.getStatus() != 1) { throw new BusinessException("菜品【" + item.getDishName() + "】已下架"); } if (dish.getStock() < item.getQuantity()) { throw new BusinessException("菜品【" + dish.getName() + "】库存不足"); } OrderDetail detail = new OrderDetail(); detail.setDishId(dish.getId()); detail.setDishName(dish.getName()); detail.setDishPrice(dish.getPrice()); detail.setQuantity(item.getQuantity()); detail.setSubtotal(dish.getPrice().multiply(new BigDecimal(item.getQuantity()))); total = total.add(detail.getSubtotal()); details.add(detail); // 3. 扣减库存，条件里带上 stock >= quantity 防止超卖 int rows = dishDao.deductStock(dish.getId(), item.getQuantity()); if (rows == 0) { throw new BusinessException("菜品【" + dish.getName() + "】库存不足"); } } // 4. 生成订单号并保存订单 Order order = new Order(); order.setOrderNo(generateOrderNo()); order.setUserId(userId); order.setTotalAmount(total); order.setStatus(OrderStatus.WAIT_PAY); order.setRemark(remark); orderDao.insert(order); // 5. 批量保存明细 for (OrderDetail detail : details) { detail.setOrderId(order.getId()); orderDetailDao.insert(detail); } return order; }代码里有两处细节值得反复琢磨。第一处是库存扣减时，我先查库存再在Update语句的where条件里带上库存数量限制，UPDATE dish SET stock = stock - #{quantity} WHERE id = #{id} AND stock >= #{quantity}，这样即使两个用户同时下单，数据库也会保证不会扣成负数。第二处是事务注解@Transactional，这个方法内任何一步抛出异常，前面插入的订单和明细都会回滚，不会出现半截订单的脏数据。这两点无论写进论文还是应对答辩，都是实打实的硬通货。
3.4 前端渲染与分页查询的常见坑
SSM项目的页面我建议用JSP加JSTL标签库，不要引入太复杂的前端框架。JSP可以直接在后面通过EL表达式取出Model里的数据，配合Bootstrap写样式，开发效率高，也符合SpringMVC传统技术栈。
分页功能是每篇毕设论文都绕不开的功能点。我推荐使用PageHelper插件，用法简单且效果稳定：查询前调用PageHelper.startPage(pageNum, pageSize)，紧接着执行MyBatis的查询方法，返回的结果用PageInfo包装，前端就可以拿到总页数和当前页的数据列表。
PageHelper.startPage(pageNum, pageSize); List<OrderVO> orderList = orderDao.selectOrderList(userId, status); PageInfo<OrderVO> pageInfo = new PageInfo<>(orderList);这里有两个实战问题要提醒。一是PageHelper.startPage一定要放在紧接着要分页的那条查询语句之前，中间不能穿插其他查询，否则会作用到错误的SQL上；二是列表页里如果要对某个状态字段做中文映射，比如把1映射成“待支付”，不要在前端写一堆if判断，我建议在SQL查询时就通过CASE WHEN查出状态描述字段，后端直接用Map接收，页面只负责展示，维护起来干净得多。
4. 从环境搭建到部署运行的全流程实操
4.1 本地开发环境准备
拿到源码之后，第一步搭建环境，这一步出问题的人特别多。我直接给一套稳定组合：JDK 1.8、Maven 3.6.3、Tomcat 8.5、MySQL 5.7，开发工具用IntelliJ IDEA。如果你本机装的是MySQL 8.x也没有问题，但JDBC驱动需要换成mysql-connector-java8.x版本，并且在JDBC连接URL里加上serverTimezone=Asia/Shanghai，不然会报时区错误。
JDK版本这里特别强调一下：SSM项目的依赖和配置基本都是在JDK 8环境下验证过的，如果你用JDK 17，一方面部分老版本Spring的字节码操作可能出问题，另一方面Maven编译时还会遇到“源发行版17需要目标发行版17”的提示。为了省事，直接装JDK 8，IDEA里把Project SDK和Maven编译级别都设置成1.8。
4.2 Maven依赖与项目初始化
项目用Maven管理依赖，核心依赖尽可能使用稳定兼容的版本组合。Spring用5.3.x，MyBatis用3.5.x，MyBatis-Spring用2.0.x，MySQL驱动用8.0.x，数据库连接池用Druid或者C3P0都行。下面是一份我常用的pom.xml依赖清单，直接照抄能少踩很多版本冲突的坑。
<properties> <spring.version>5.3.24</spring.version> <mybatis.version>3.5.10</mybatis.version> </properties> <dependencies> <!-- Spring核心 --> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-context</artifactId> <version>${spring.version}</version> </dependency> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-webmvc</artifactId> <version>${spring.version}</version> </dependency> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-jdbc</artifactId> <version>${spring.version}</version> </dependency> <!-- MyBatis --> <dependency> <groupId>org.mybatis</groupId> <artifactId>mybatis</artifactId> <version>${mybatis.version}</version> </dependency> <dependency> <groupId>org.mybatis</groupId> <artifactId>mybatis-spring</artifactId> <version>2.0.7</version> </dependency> <!-- MySQL驱动 --> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>8.0.30</version> </dependency> <!-- Druid连接池 --> <dependency> <groupId>com.alibaba</groupId> <artifactId>druid</artifactId> <version>1.2.9</version> </dependency> <!-- JSTL --> <dependency> <groupId>javax.servlet</groupId> <artifactId>jstl</artifactId> <version>1.2</version> </dependency> <dependency> <groupId>com.github.pagehelper</groupId> <artifactId>pagehelper</artifactId> <version>5.3.1</version> </dependency> </dependencies>依赖版本一定要以互相兼容为第一原则，不要下意识选择官网最新版。我见过很多项目跑不起来，都是因为MyBatis-Spring 3.x搭配MyBatis 4.x导致API不兼容，最终排查半天只能回退版本。
4.3 数据初始化与测试数据准备
数据库脚本通常包括建库建表语句和初始数据，项目压缩包里自带sql文件，用Navicat或者命令行导入即可。初始数据必须保证以下内容：至少一个管理员账号、一个食堂工作人员账号、一个测试用户账号，菜品种类要覆盖至少三个分类，每个分类下至少四个菜品。
测试数据为什么要准备这么足？因为论文里的功能截图、系统测试表格都要基于真实数据来展示。你不可能只用一个菜品就证明“分页查询功能正常”，也不可能在只有两条记录的情况下展示分页效果。另外，我建议给测试账号统一使用一个容易记的密码，比如123456，避免写成代码注释或者论文的时候还要去数据库里查。
4.4 打包部署与运行检查
IDEA配置Tomcat运行项目有两种方式：一种是直接配置Tomcat Server，选择war exploded的部署方式，这种方式适合开发和调试；另一种是用mvn clean package打成war包，扔到Tomcat的webapps目录下，这种方式更适合最后写文档和演示。
启动之后，按顺序做一遍检查：项目根路径能否访问登录页，能否正常登录跳转到首页，菜品列表是否能带图片显示，下单成功后订单列表里是否能查到对应记录。如果其中任何一步报错，不要着急，直接看IDEA控制台的完整堆栈信息，错误类型和出错的代码行都会打印出来。这里诚实地说，SSM项目第一次启动大概率会报错，但错误类型就那么几类，你只要看得懂日志，基本都能自己排查掉。
5. 论文写作与答辩准备的实战建议
5.1 论文框架怎么搭才像一篇成熟的毕设论文
论文的结构直接决定评审老师的第一印象。社区食堂供餐系统的论文不需要标新立异，按标准框架写反而最稳。完整的章节结构建议如下：
| 章节 | 核心内容 | 写作要点 |
|---|---|---|
| 第一章 绪论 | 研究背景与意义、国内外研究现状、论文组织结构 | 重点写“社区食堂的信息化管理需求”，不要空谈互联网发展 |
| 第二章 相关技术介绍 | SSM框架、MySQL、Tomcat、前端技术 | 每种技术的核心特性写清楚，不要大段复制框架官方文档 |
| 第三章 需求分析 | 可行性分析、角色分析、功能需求、非功能需求 | 用用例图辅助描述，每个角色对应的功能点要列全 |
| 第四章 系统设计 | 总体架构设计、功能模块设计、数据库设计、类设计 | 贴ER图、表结构说明、核心类的属性与方法 |
| 第五章 系统实现 | 开发环境、关键功能实现、页面展示 | 每个功能模块配界面截图和核心代码片段，代码不需要全贴 |
| 第六章 系统测试 | 测试环境、功能测试用例、测试结果 | 用表格整理测试用例，证明系统满足需求 |
| 第七章 总结与展望 | 总结完成的工作、指出不足、展望未来优化 | 真实客观，不要为了“展望”而空写 |
写论文最忌讳的问题是第二章抄一堆框架介绍凑字数，到了第五章系统实现反而只有截图没有代码逻辑。老师看论文最在意的逻辑是“你说你要做什么，你怎么设计，你怎么实现，最后验证了没有”这一条线。每一章都要和前后章节呼应，比如数据库设计里提到订单状态字段，第五章实现订单模块时就要展示状态更新的代码。
5.2 图表、测试数据与工作量展示技巧
论文和工作量直接挂钩的就是图表数量。我统计了一下，一个完整的毕设论文至少应该有五类图：系统用例图、系统功能结构图、数据库ER图、关键业务流程时序图、系统部署架构图。这些图不需要画得特别复杂，但一定要规范。工具上我建议用ProcessOn在线画用例图和流程图，用PowerDesigner或者Navicat自带的模型工具生成ER图，界面截图使用真实系统页面，不要用网上找的素材顶替。
测试章节是最容易让论文变水的地方。很多同学到了测试章节就写“系统运行正常，满足需求”，这样写等于没有写。正确做法是把核心功能都变成可验证的测试用例，每个用例包含编号、测试项、操作步骤、预期结果、实际结果、是否通过。比如“登录功能测试”这个用例，就输入用户名、密码、点击登录、预期跳转主页，这样六要素写清楚，测试表就显得非常专业，工作量自然也就写出来了。
5.3 答辩环节高频问题与应答思路
答辩时老师一定会抓住技术框架和核心业务提问，提前准备这些高频问题的应答思路会非常从容。
“为什么选SSM不选Spring Boot？”我的建议是回答两句话：一是SSM更贴近框架底层原理，能够更清楚地展示Spring容器、MVC分发和ORM映射的工作过程，对深入理解Java后端有帮助；二是本系统功能复杂度适中，使用SSM完全能够覆盖并保持代码清晰可控。这样既承认了Spring Boot的优势，又说明了自己做这个选择的技术考量。
“怎么避免订单并发时超卖？”回答思路是：数据库层面使用乐观控制，在扣减库存的SQL中通过stock >= quantity条件保证不会扣成负数，加上事务回滚保证数据一致性。条件允许还可以补充，如果要支持更强的并发性能，可以引入Redis预扣库存，但毕设阶段用数据库方案已经足够。
“ArrayList和LinkedList有什么区别”这类Java基础题也可能出现，因为老师默认你用了Java就必须掌握集合类。这些不必临阵磨枪，建议把Java基础面试题里最常见的30道过一遍，至少做到能说出关键概念，包括HashMap底层原理、==和equals的区别、异常处理机制、线程同步的几种方式。
6. 常见问题排查与避坑技巧实录
6.1 毕设高频报错速查表
SSM项目运行过程中遇到的问题，绝大多数都是配置问题而不是代码逻辑问题。我把这些年反复出现的报错整理成一张速查表，对着排查能省下大量时间。
| 报错现象 | 常见原因 | 解决方案 |
|---|---|---|
| 启动后访问项目显示404 | 部署名称不对或Artifact没配置好 | 检查IDEA中Tomcat的Deployment配置，确认访问路径和项目context path一致 |
| 页面报500，控制台显示NullPointerException | Service或Dao对象没有被Spring创建 | 检查组件扫描包路径是否正确，是否缺少@Autowired或@Resource注解 |
| 控制台提示Invalid bound statement (not found) | MyBatis的Mapper接口和XML映射文件没有绑定 | 检查Mapper接口名和XML文件的namespace是否一致，方法id是否对应 |
| Mapped Statements collection already contains value | Mapper XML重复加载 | 检查mapperLocations配置是否同时扫描了多个重复路径 |
| 中文保存到数据库变成问号 | 表字符集不是utf8mb4 | 建库时指定字符集，JDBC连接URL添加characterEncoding=utf8 |
| 时区相关的SQLException | MySQL 8与驱动版本或连接URL不匹配 | 使用mysql-connector-java8.x，URL加serverTimezone=Asia/Shanghai |
| Tomcat启动端口被占用 | 端口被其他进程连接 | 打开任务管理器结束占用进程，或修改Tomcat配置中的端口号 |
| Maven依赖下载不下来或插件报错 | 仓库源不稳定或依赖版本冲突 | 配置阿里云公共仓库镜像，统一Spring和MyBatis相关版本 |
排查报错最关键的工具是控制台堆栈信息，很多人一看到红字就慌，其实堆栈信息里第一行就是真正的问题原因。先把完整堆栈复制到文本文件里，对照速查表定位关键词，比反复重启项目有效得多。
6.2 我实践中反复踩过的几个细节坑
第一个坑是字段命名撞上SQL关键字。我在设计订单表时顺手把字段名写成order，结果随便一条select语句都报语法错误，后来才想起来order是SQL中的排序关键字。这类问题在项目开始阶段用Navicat建表跑一遍简单的增删改查就能提前发现，不要等到代码写了一半才改表名，那样改动量会扩大好几倍。
第二个坑是Lombok注解导致实体类方法找不到。项目里用了@Data简化实体类代码，但团队里某个同事的IDEA一直没有安装Lombok插件，编译就报找不到getter和setter方法。后来我统一要求新建工程后第一件事检查Lombok插件是否安装，如果没有安装就用IDEA的插件市场安装，不然实体类写再多也是个摆设。
第三个坑是事务注解失效。自己在同一类中调用另一个带@Transactional的方法，Spring的事务是基于AOP代理实现的，自调用绕过了代理对象，事务配置就完全失去了作用。正确做法是把需要事务的方法拆到另一个Service类里，或者注入自身代理来调用。这个坑非常隐蔽，因为代码不会报错，只有在数据异常回滚失败的时候才会暴露。
第四个坑是时间类型的使用。实体类里如果使用LocalDateTime，而MyBatis版本在3.4.0之前，默认的TypeHandler是不支持的新日期类型的，查询时会直接报错。要么把实体类时间字段统一定义为java.util.Date，要么升级MyBatis版本。我后来为了省事，项目里全部使用Date类型，控制层展示时再用SimpleDateFormat格式化，兼容性最好，答辩时也不会给自己增加不必要的解释成本。
第五个坑是分页插件与自定义SQL冲突。PageHelper本质上是通过拦截器修改原始SQL实现分页，如果项目里有复杂的多表联查SQL，分页插件拼接count语句时偶尔会生成不正确的统计SQL。遇到这种情况，不要硬斥分页插件，直接使用@Select注解自己写limit参数实现分页，反而更可控。
我在给学弟调这类项目时最有体会的一点是，多数问题不是代码复杂，而是环境和配置不一致。把环境匹配好，SSM框架搭起来无非就是几十行配置的事；把数据库表建规范，后端代码写起来就是顺着业务流一路走下去。如果你准备做或者正在做这个题目，我始终建议先把数据库脚本执行完，再跑通一条“用户登录、浏览菜品、下单、食堂接单”的最小闭环，最后再补功能和写论文。核心链路通了，后面的所有功能都只是往这个主干上做加法，很多问题的解决思路也会在跑通闭环的过程中自然清晰起来。
