企业官网建设流程全解析

简介：这是一套面向Java初学者与毕业设计学生的共享厨房信息管理系统实战项目，基于SSM（Spring+SpringMVC+MyBatis）框架开发，采用JSP+HTML构建前端界面，覆盖用户预约、厨房管理、设备维护、订单结算等核心业务场景，助力学生高效完成课程设计、期末大作业或高分毕业设计。资源包共1214个文件，含96个Java后端逻辑类、86个JSP页面、146个CSS样式与364个JS交互脚本，辅以MySQL数据库脚本（2个.sql）、配置文件及UI资源（PNG/GIF/JPG等），整体15.45MB，结构清晰、注释完整，新手可快速理解模块划分与调用关系。项目已通过严格调试，兼容Tomcat 7.x/8.x与MySQL 5.7，配套提供IDEA工程配置说明及Navicat数据库操作指引。下载即用，无需二次开发即可部署运行，是掌握Java Web全栈开发流程的典型教学案例。

1. 项目背景与核心价值

最近在帮几个计算机专业的学弟学妹看毕业设计，发现一个挺有意思的现象：很多同学在选题时，要么选得过于宏大，比如“基于深度学习的智慧城市交通调度系统”，要么选得过于简单，比如“学生信息管理系统”。前者容易导致项目虎头蛇尾，核心功能实现不了；后者又显得过于陈旧，缺乏新意，在答辩时不容易出彩。而“共享厨房”这个选题，恰好踩在了一个非常巧妙的平衡点上。它听起来贴近生活，有现实的应用场景（比如大学城周边的合租公寓、创业孵化器里的公共空间），技术栈又是非常经典和成熟的SSM（Spring+SpringMVC+MyBatis）配合JSP/HTML，既能完整地展示一个Web应用从数据库设计到前端展示的全流程，又不会因为技术过于前沿或复杂而让开发者陷入泥潭。

这个项目本质上是一个B/S架构的信息管理系统。它的核心价值在于，通过一个线上平台，将线下分散的厨房资源（场地、设备）和用户需求（预约使用、费用结算、设备报修）连接起来。对于开发者而言，你需要考虑用户角色（普通用户、厨房管理员、系统管理员）、业务流程（浏览、预约、支付、评价、报修）、以及后台的数据管理。这几乎涵盖了管理信息系统的所有典型模块：用户管理、资源管理、订单管理、财务管理、信息发布。用SSM框架来实现，可以让你深入理解如何用Spring的IOC容器来管理业务对象、用SpringMVC处理Web请求和响应、用MyBatis优雅地操作数据库，再用JSP和HTML将这些数据动态地呈现给用户。这比单纯做一个增删改查（CRUD）的demo要有深度得多。

我见过不少毕业设计源码，很多只是把代码堆上去，能跑通就行，但里面的设计逻辑、异常处理、安全性考虑几乎为零。比如，用户预约时间冲突了怎么办？支付状态如何与订单状态联动？敏感操作（如删除订单、修改金额）有没有权限校验？这些细节才是区分“作业”和“作品”的关键。接下来，我就结合这个“共享厨房信息系统”的典型实现，拆解一下从零开始构建这样一个项目，你需要关注哪些核心环节，以及如何避开那些新手最容易踩的坑。

2. 技术选型与项目架构解析

为什么是SSM+JSP/HTML？这个组合在Java Web开发领域被称为“经典三件套”，虽然现在更流行SpringBoot+Thymeleaf/Vue前后端分离，但对于毕业设计来说，前者有不可替代的优势。SSM框架整合了企业级开发的核心思想，手动整合它们的过程本身就是一个极佳的学习过程。你能清楚地知道Spring的applicationContext.xml配置文件里每一个bean的作用，知道SpringMVC的DispatcherServlet如何分发请求，知道MyBatis的SqlSession是如何从SqlSessionFactory诞生的。这种理解对于构建扎实的Java Web基础至关重要。

2.1 后端核心：SSM框架分工与整合

Spring：扮演“大管家”角色。它的核心是IOC（控制反转）容器，项目里所有的Service（业务逻辑层）、Dao（数据访问层，在MyBatis中通常叫Mapper）、Controller（控制层）对象，以及数据库连接池、事务管理器等，都由Spring来创建和管理。在共享厨房项目中，你会有一个KitchenService，里面包含预约、取消、查询等方法。这个方法内部可能会调用OrderMapper（插入订单）、UserMapper（更新用户积分）等多个Mapper。如果没有Spring，你需要自己new这些对象，并处理它们之间复杂的依赖关系。有了Spring，你只需要在类上标注@Service、@Repository、@Autowired，容器就会自动帮你组装好。更重要的是，Spring的声明式事务管理（@Transactional）对于这个项目至关重要。想象一下用户预约厨房的流程：扣减用户余额、生成订单记录、更新厨房时段状态。这三个数据库操作必须作为一个整体，要么全部成功，要么全部失败。用@Transactional注解一个方法，Spring就能帮你保证这一点，避免了手动处理数据库连接和回滚的繁琐与易错。

SpringMVC：扮演“前台接待”和“调度中心”角色。所有用户的HTTP请求（比如点击“预约”按钮）都先到达它这里。它的核心是DispatcherServlet。这个Servlet会根据配置（或注解）找到对应的Controller（比如OrderController）和方法（比如submitOrder），并将请求参数（如表单数据、URL参数）绑定到方法的入参上。方法执行完毕后，会返回一个结果，这个结果可能是：

1. ModelAndView对象：包含要传递给页面的数据（Model）和要渲染的JSP页面路径（View）。例如，OrderController.listMyOrders()方法查询当前用户的所有订单列表，放入Model，然后返回视图名"myOrders"，SpringMVC就会找到/WEB-INF/jsp/myOrders.jsp文件来渲染，并将订单列表数据传递过去。
2. 一个字符串：直接表示视图名。
3. 被@ResponseBody注解的对象：直接转换为JSON返回给前端（虽然本项目主要用JSP，但部分异步请求如“检查厨房是否可预约”可以用到）。

MyBatis：扮演“数据库操作专家”角色。它是一个半自动化的ORM框架，比Hibernate更轻量、更灵活。你的主要工作是在XML映射文件（或注解）里编写SQL语句。对于共享厨房项目，复杂的多表关联查询非常常见。例如，查询一个订单的详情，需要关联订单表、用户表、厨房表、时段表。用MyBatis的<resultMap>可以非常清晰地将查询结果映射成一个复杂的Java对象（OrderDetailDTO），这是它的一大优势。你不需要像JDBC那样手动解析ResultSet，也不像某些全自动ORM框架那样在复杂查询时可能产生性能低下的SQL。

整合关键：整合这三个框架，核心是web.xml和Spring的配置文件。在web.xml中，你需要配置ContextLoaderListener来启动Spring的根容器（主要管理Service和Mapper），配置DispatcherServlet来启动SpringMVC的容器（主要管理Controller）。两者是父子容器的关系。MyBatis的SqlSessionFactory则作为Spring容器中的一个Bean被创建，其依赖的数据源（DataSource）和Mapper接口扫描路径也在Spring配置中完成。这个过程看似繁琐，但网上有大量成熟的模板，理解其原理后，配置起来并不困难。

2.2 前端呈现：JSP与HTML的协作

在这个项目中，JSP（JavaServer Pages）承担了动态页面渲染的主要工作，而HTML/CSS/JavaScript则是构建页面的基础技术。

JSP的角色：它本质是一个Servlet。当用户请求一个.jsp页面时，服务器（如Tomcat）会将其编译成Servlet来执行。它的强大之处在于可以在HTML中嵌入Java代码（通过<% ... %>脚本片段、<%= ... %>表达式）和JSTL标签。在共享厨房系统中，几乎所有需要动态数据的页面都是JSP：

• 厨房列表页：用JSTL的<c:forEach>循环遍历从Controller传过来的List<Kitchen>对象，动态生成每个厨房的卡片。
• 我的订单页：根据订单状态（待支付、已预约、已完成、已取消），使用<c:if>或<c:choose>标签显示不同的操作按钮（如“去支付”、“取消预约”、“评价”）。
• 后台管理页：动态生成数据表格，并可能包含分页逻辑。

HTML/CSS/JavaScript的基础作用：JSP负责产出动态的HTML内容，而页面的布局、样式和交互则由这三者决定。一个常见的误区是毕业生在JSP里写满<% ... %>，导致页面难以维护。好的做法是：JSP只负责数据注入和简单的逻辑判断，复杂的页面结构和样式交给HTML/CSS，动态交互（如表单验证、Ajax请求）交给JavaScript（或jQuery）。例如，一个厨房预约表单，其HTML骨架和CSS样式是固定的，JSP只负责在页面加载时，可能将厨房ID、默认预约日期等数据注入到对应的表单元素中。

一个重要的实践建议：为了安全性和清晰的MVC分层，通常会将JSP文件放在/WEB-INF/目录下（如/WEB-INF/jsp/）。因为/WEB-INF/下的内容不能直接被客户端访问，必须通过Controller跳转。这样，你就强制了所有页面请求都必须经过后台逻辑处理，避免了直接访问JSP文件可能带来的问题。

2.3 数据库设计核心思路

数据库设计是项目的基石，设计得好，后续开发事半功倍。共享厨房系统的核心实体至少有以下几个：

1. 用户表 (t_user/user)：存储用户基本信息。除了id、username、password（务必加密存储，如使用BCrypt）、phone、email外，还应考虑balance（余额，用于支付）、role（角色：0-普通用户，1-厨房管理员，2-系统管理员）、status（账号状态）。
2. 厨房表 (t_kitchen)：描述厨房资源。字段包括id、name、location、description、image_urls（图片，可考虑用JSON字符串或单独的表存储）、facilities（设施描述）、price_per_hour（每小时单价）、status（0-可用，1-维护中）。
3. 预约时段表 (t_time_slot)：这是实现预约功能的关键。它可以与厨房表关联。一种设计是：id、kitchen_id、date（日期）、start_time、end_time、status（0-可预约，1-已被预约，2-不可用）。另一种更灵活的设计是将时段规则（如每天9:00-22:00，每2小时为一个时段）与具体日期的预约记录分开。
4. 订单表 (t_order)：核心业务表。id、order_no（唯一订单号，可用时间戳+随机数生成）、user_id、kitchen_id、time_slot_id（或具体的date、start_time、end_time）、total_amount、status（订单状态：待支付、已预约、进行中、已完成、已取消、退款中、已退款）、create_time、pay_time等。
5. 支付记录表 (t_payment)：与订单表一对一或一对多（一次订单可能分多次支付）。记录支付渠道、支付平台交易号、支付金额、支付状态。
6. 评价表 (t_review)：id、order_id、user_id、rating（评分）、content、images、create_time。
7. 设备报修表 (t_repair)：id、kitchen_id、user_id（报修人）、device_name、description、images、status（待处理、处理中、已修复）、create_time、handle_time、handler_id（处理的管理员）。

设计要点：

• 状态字段枚举化：像order_status、user_status这类字段，在Java中应使用枚举类（enum）来定义，避免在代码中硬编码数字0、1、2，提高可读性和可维护性。
• 索引优化：在t_order表的user_id、status、create_time上建立复合索引，可以极大提升“查询我的订单”这类操作的效率。
• 数据一致性：预约时段的状态更新和订单创建必须在一个事务内完成，防止超卖。

3. 核心功能模块实现与避坑指南

有了清晰的架构和数据库设计，我们就可以着手实现核心功能了。这里我挑几个最容易出问题，也最能体现你设计能力的功能点来详细讲。

3.1 厨房预约与并发控制

这是系统的核心业务，逻辑并不复杂：用户选择厨房、选择可用时段、提交订单。但并发问题是这里的头号杀手。假设厨房A在10:00-12:00这个时段只剩最后一个名额，两个用户几乎同时点击了“预约”。

错误示范（典型新手坑）：

1. 前端查询时段状态，显示“可预约”。
2. 用户点击提交。
3. 后端代码顺序执行：a. 再次查询时段状态 -> b. 如果可预约，则插入订单 -> c. 更新时段状态为“已预约”。 在并发情况下，两个请求可能同时通过步骤a的检查，然后都执行b和c，导致一个时段被重复预约。

正确解决方案：利用数据库的悲观锁或乐观锁。

方案一：悲观锁（SELECT ... FOR UPDATE）在MyBatis的Mapper XML中，查询可用时段时加上FOR UPDATE。这会在事务内锁定这条记录，直到当前事务提交，其他事务无法再修改它。

<!-- TimeSlotMapper.xml --> <select id="selectSlotForUpdate" parameterType="int" resultType="TimeSlot"> SELECT * FROM t_time_slot WHERE id = #{id} AND status = 0 FOR UPDATE </select>

然后在Service方法中：

@Transactional // 事务非常重要！ public OrderResult reserveKitchen(ReserveRequest request) { // 1. 加锁查询时段 TimeSlot slot = timeSlotMapper.selectSlotForUpdate(request.getSlotId()); if (slot == null) { throw new BusinessException("该时段已被预约或不可用"); } // 2. 创建订单（业务逻辑） Order order = createOrder(request, slot); orderMapper.insert(order); // 3. 更新时段状态 slot.setStatus(1); timeSlotMapper.update(slot); // 4. 其他操作（如扣减余额等） // ... return OrderResult.success(order); }

这个方法保证了在检查时段、创建订单、更新时段状态这个序列中，对同一条时段记录的操作是串行的。

方案二：乐观锁（使用版本号version）在t_time_slot表中增加一个version字段（整数类型，默认0）。每次更新时，都带上版本号检查。

UPDATE t_time_slot SET status = 1, version = version + 1 WHERE id = #{id} AND status = 0 AND version = #{oldVersion}

执行这条SQL后，检查受影响的行数（int affectedRows = timeSlotMapper.updateSlotWithVersion(...)）。如果affectedRows为0，说明更新失败（大概率是被别人抢先预约了），此时需要回滚事务，并给用户返回友好的错误提示“手速慢了，该时段已被抢订”。

实操心得：对于共享厨房这种并发压力不会极端巨大的场景，我个人更倾向于使用乐观锁。因为它避免了长期锁定记录，性能更好，也更符合“冲突发生较少”的预期。在Service层，你需要捕获更新失败的情况，并进行重试或直接返回失败。悲观锁更适用于库存扣减、秒杀等冲突频率极高的场景，但要注意锁的粒度，避免锁住太多数据导致性能瓶颈。

3.2 订单状态流转与设计模式应用

订单的状态管理是另一个容易混乱的地方。状态包括：待支付->已预约（支付成功后）->进行中（预约时间开始前某时间点或用户扫码签到）->已完成（预约时间结束后或用户确认完成）->已取消（用户取消或超时未支付）。还可能存在退款中、已退款等子状态。

如果用一个巨大的if-else或switch-case在OrderService里处理所有状态变更，代码会变得难以维护。这里可以引入状态模式来优雅地解决。

状态模式实践：

1. 定义订单状态接口：OrderState

   public interface OrderState { void pay(Order order); // 支付 void cancel(Order order); // 取消 void complete(Order order); // 完成 // ... 其他操作 }

2. 为每个状态创建实现类：

   @Component("pendingPaymentState") // 交给Spring管理 public class PendingPaymentState implements OrderState { @Override public void pay(Order order) { // 检查支付逻辑，调用支付网关 // 支付成功后，变更订单状态 order.setStatus(OrderStatusEnum.RESERVED.getCode()); // 可能需要发布一个“支付成功”领域事件，来触发后续操作（如发送短信） applicationContext.publishEvent(new OrderPaidEvent(this, order)); } @Override public void cancel(Order order) { // 待支付状态下取消，直接关闭订单 order.setStatus(OrderStatusEnum.CANCELLED.getCode()); // 释放关联的厨房时段资源 releaseTimeSlot(order); } // complete方法在待支付状态下可能是无效操作，可以抛出异常或忽略 }

   @Component("reservedState") public class ReservedState implements OrderState { @Override public void cancel(Order order) { // 已预约状态下取消，需要判断是否在可免费取消时间内 if (canFreeCancel(order)) { // 免费取消，触发退款流程 startRefund(order); order.setStatus(OrderStatusEnum.REFUNDING.getCode()); } else { // 扣除违约金后再退款 deductPenalty(order); startRefund(order); order.setStatus(OrderStatusEnum.REFUNDING.getCode()); } releaseTimeSlot(order); } }

3. 在订单实体中持有状态对象：订单类Order中不再只有status一个整数，而是关联一个状态对象。

   public class Order { private Integer statusCode; private OrderState state; // 瞬态，不持久化 // 根据statusCode从Spring容器中获取对应的OrderState Bean public OrderState getState() { if (this.state == null) { String beanName = OrderStatusEnum.getByCode(this.statusCode).getStateBeanName(); this.state = applicationContext.getBean(beanName, OrderState.class); } return this.state; } public void pay() { this.getState().pay(this); } public void cancel() { this.getState().cancel(this); } }

4. 在Service中调用：OrderService中的业务逻辑变得非常清晰。

   @Service public class OrderService { public void cancelOrder(Long orderId) { Order order = orderMapper.selectById(orderId); // 权限校验... // 核心操作：委托给状态对象 order.cancel(); // 更新订单到数据库 orderMapper.update(order); } }

避坑指南：状态模式将不同状态下的行为分散到各自的类中，符合“开闭原则”。当你需要增加一个新的状态（比如“申诉中”）或修改某个状态的行为时，只需要新增或修改一个类，不会影响到其他状态的逻辑。这比在一个几千行的OrderService里修修补补要安全、清晰得多。这是毕业设计中能体现你设计能力的一个亮点。

3.3 后台管理模块的通用性设计

后台管理模块通常包含大量的表格数据展示、搜索、分页、增删改查操作。为每个实体（用户、厨房、订单）都写一套类似的Controller、Service和JSP页面，会产生大量重复代码。这里可以借鉴“通用后台”的思想。

1. 前端页面组件化： 使用JSP的<%@ include file="..." %>指令或自定义标签，将通用的页面片段抽离出来。例如：

• common/table_head.jsp：包含表格的标题行。
• common/pagination.jsp：分页组件，接收总记录数、当前页、每页大小等参数。
• common/search_bar.jsp：通用的搜索框，可以根据不同实体传递不同的搜索字段配置。

2. 后端通用Service与Controller： 对于简单的增删改查，可以设计一个BaseService<M, E>（M是Mapper类型，E是实体类型）和BaseController。

public abstract class BaseController<E> { @Autowired protected BaseService<E> baseService; @RequestMapping("/list") public ModelAndView list(@RequestParam Map<String, Object> params, Page page) { PageResult<E> pageResult = baseService.selectPage(params, page); ModelAndView mav = new ModelAndView("common/list_page"); // 通用列表页 mav.addObject("pageResult", pageResult); mav.addObject("entityName", getEntityName()); // 子类实现，返回“用户”、“厨房”等 mav.addObject("fieldList", getFieldList()); // 子类实现，返回要展示的字段配置 return mav; } // 其他通用方法：add, edit, save, delete... }

然后，UserController继承BaseController<User>，并实现getEntityName()和getFieldList()方法即可。这样，后台管理的基础CRUD功能就通过继承实现了复用。

3. 动态查询与MyBatis的<if>标签： 后台的搜索条件往往是动态的。MyBatis的动态SQL功能可以完美应对。

<!-- 在UserMapper.xml中 --> <select id="selectByCondition" parameterType="map" resultType="User"> SELECT * FROM t_user <where> <if test="username != null and username != ''"> AND username LIKE CONCAT('%', #{username}, '%') </if> <if test="role != null"> AND role = #{role} </if> <if test="status != null"> AND status = #{status} </if> <if test="startCreateTime != null"> AND create_time >= #{startCreateTime} </if> <if test="endCreateTime != null"> AND create_time <= #{endCreateTime} </if> </where> ORDER BY create_time DESC </select>

这样，BaseService中的selectPage方法就可以构建一个Map参数，将前端传递的搜索条件原样传给Mapper，实现灵活的查询。

经验之谈：通用后台的设计能节省大量开发时间，但要注意边界。对于业务逻辑特别复杂的实体（如订单，涉及状态流转、财务结算），可能不适合完全套用通用模板，需要单独实现其管理逻辑。通用性设计体现的是你的抽象思维和代码复用能力，在答辩时可以向老师重点阐述这一块的设计思路。

4. 开发环境搭建、部署与常见问题排查

一个能跑起来的项目只是第一步，一个配置清晰、易于部署、能应对常见异常的项目才算是合格的作品。

4.1 从零开始的环境搭建要点

1. 依赖管理（Maven）： 在pom.xml中，要清晰地管理所有依赖。除了SSM核心依赖（spring-webmvc, spring-jdbc, mybatis, mybatis-spring），还需要注意：

• 数据库驱动：mysql-connector-java（根据你的MySQL版本选择）。
• 连接池：推荐使用HikariCP，它是目前性能最好的JDBC连接池之一。
• JSTL标签库：jstl和taglibs-standard-impl，用于在JSP中使用<c:forEach>等标签。
• 日志：slf4j-api配合logback-classic，避免使用System.out.println。
• 工具包：commons-lang3,hutool-all（国产优秀工具包，简化很多操作）等。
• 测试：junit。

2. 配置文件分层： 不要把所有配置都堆在applicationContext.xml里。建议分拆：

• jdbc.properties：存放数据库连接、连接池参数。
• spring-dao.xml：配置数据源、事务管理器、MyBatis的SqlSessionFactory。
• spring-service.xml：配置扫描@Service注解。
• spring-mvc.xml：配置扫描@Controller、视图解析器（将视图名解析到/WEB-INF/jsp/目录）、静态资源映射、文件上传解析器等。
• mybatis-config.xml（可选）：MyBatis的全局配置，如开启驼峰命名映射等。

3. 视图解析器配置： 这是让JSP正常工作的关键。

<!-- 在spring-mvc.xml中 --> <bean class="org.springframework.web.servlet.view.InternalResourceViewResolver"> <property name="prefix" value="/WEB-INF/jsp/"/> <property name="suffix" value=".jsp"/> </bean>

4.2 部署到Tomcat的注意事项

1. 项目打包：使用Maven的package命令生成war文件。确保pom.xml中<packaging>war</packaging>。
2. Servlet API版本：确保你的项目使用的Servlet版本与目标Tomcat版本兼容。Tomcat 8.5对应Servlet 3.1，Tomcat 9对应Servlet 4.0。在pom.xml中，javax.servlet-api依赖的<scope>应设为provided，因为Tomcat容器本身会提供。
3. 上下文路径（Context Path）：将war包放入Tomcat的webapps目录后，默认上下文路径是war包的文件名（不含.war后缀）。你也可以在server.xml中配置，或在webapps下创建ROOT文件夹替换默认根路径。在代码中获取资源路径时，不要硬编码，应使用${pageContext.request.contextPath}。
4. 静态资源访问：在spring-mvc.xml中，需要配置<mvc:resources>来放行CSS、JS、图片等静态资源，否则它们会被DispatcherServlet拦截导致404。

   <mvc:resources mapping="/static/**" location="/static/"/> <mvc:resources mapping="/upload/**" location="file:${upload.base.path}"/> <!-- 上传文件路径 -->

4.3 开发与调试中的高频问题

问题一：JSP页面无法跳转，一直报404错误。

• 排查步骤：
  1. 检查Controller方法返回值是否正确。返回的字符串视图名是否与spring-mvc.xml中配置的prefix和suffix能拼接成正确的物理路径？例如返回"kitchen/list"，最终会查找/WEB-INF/jsp/kitchen/list.jsp。
  2. 检查@RequestMapping注解路径。确保浏览器访问的URL能映射到正确的Controller方法。
  3. 检查Tomcat控制台是否有编译错误。JSP第一次访问时会编译成Servlet，如果JSP文件本身有语法错误（比如标签未闭合），会在控制台抛出异常，导致页面无法显示。
  4. 一个常见坑：如果Controller方法使用了@ResponseBody注解，它返回的是JSON数据，而不是视图名。确认你是否需要这个注解。

问题二：页面显示乱码。

• 解决方案：这是一个“三码合一”问题。
  1. 数据库编码：确保MySQL数据库、表、字段的字符集为utf8mb4（支持emoji）。
  2. 连接字符串编码：在JDBC连接URL中指定字符集：jdbc:mysql://localhost:3306/shared_kitchen?useUnicode=true&characterEncoding=utf-8&useSSL=false&serverTimezone=Asia/Shanghai。
  3. JSP页面编码：在JSP文件头部指定：<%@ page contentType="text/html;charset=UTF-8" language="java" %>。同时，确保文件本身的物理编码也是UTF-8（在IDE中设置）。
  4. SpringMVC编码过滤器：在web.xml中配置CharacterEncodingFilter，并设置forceEncoding为true。

     <filter> <filter-name>encodingFilter</filter-name> <filter-class>org.springframework.web.filter.CharacterEncodingFilter</filter-class> <init-param> <param-name>encoding</param-name> <param-value>UTF-8</param-value> </init-param> <init-param> <param-name>forceEncoding</param-name> <param-value>true</param-value> </init-param> </filter> <filter-mapping> <filter-name>encodingFilter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping>

问题三：MyBatis查询结果映射失败，返回字段为null。

• 排查步骤：
  1. 检查数据库字段名与实体类属性名是否匹配：默认情况下，MyBatis开启驼峰命名自动映射（mapUnderscoreToCamelCase=true）可以将user_name映射到userName。如果没开启，需要在resultMap中显式指定，或者使用@Result注解。
  2. 检查SQL语句中的别名：如果SQL中使用了AS别名，如SELECT u.name AS userName，那么resultType指定的实体类中必须有userName属性，或者resultMap中配置<result property="userName" column="userName"/>。
  3. 使用日志排查：在mybatis-config.xml中配置<setting name="logImpl" value="STDOUT_LOGGING"/>，可以在控制台看到MyBatis执行的SQL语句和参数，直接复制到数据库客户端执行，看结果是否正确。

问题四：事务不生效。

• 排查步骤：
  1. 检查方法是否为public：Spring的声明式事务基于AOP代理，只有public方法上的@Transactional注解才生效。
  2. 检查异常类型：默认情况下，只有抛出RuntimeException和Error时才会回滚。如果你抛出了Exception，需要在注解中指定：@Transactional(rollbackFor = Exception.class)。
  3. 检查是否在同一个类内部调用：如果一个Service类的methodA()（无事务）调用了同一个类的methodB()（有@Transactional），由于是通过this调用，不经过代理对象，事务不会生效。解决方法是：将methodB()移到另一个Service中，或者通过AopContext.currentProxy()获取代理对象再调用（不推荐，耦合度高）。
  4. 检查数据源和事务管理器配置：确保DataSourceTransactionManager管理的数据源与MyBatis使用的DataSource是同一个Bean。

5. 项目扩展与优化思路（让毕业设计更出彩）

完成基础功能后，如果你的时间和技术允许，可以考虑加入以下一两个扩展点，这能让你的项目在答辩时脱颖而出。

5.1 集成第三方服务：短信验证与对象存储

短信验证码登录/注册：

1. 选择服务商：阿里云、腾讯云等都有提供短信服务，有免费试用额度。
2. 流程设计：用户输入手机号 -> 前端点击“获取验证码” -> 后端生成随机6位码，存入Redis或数据库（设置过期时间，如5分钟），并调用服务商API发送短信 -> 用户输入验证码提交 -> 后端校验验证码是否正确且未过期。
3. 防刷机制：对同一手机号，限制发送频率（如60秒内只能发一次）。可以使用Redis记录上次发送时间。
4. 安全性：验证码不要直接返回给前端。登录成功后，使用JWT或Session维持登录状态。

厨房图片上传与云存储：

1. 本地存储的弊端：图片存储在项目服务器上，不利于扩容和迁移，访问速度也受服务器带宽限制。
2. 集成对象存储：使用阿里云OSS、腾讯云COS或七牛云等。它们提供简单的SDK。
3. 实现步骤：
   • 前端使用<input type="file">配合FormData进行Ajax上传。
   • 后端Controller接收MultipartFile对象。
   • 校验文件类型（通过后缀或Magic Number）和大小。
   • 生成一个唯一的文件名（如UUID + 后缀），防止覆盖。
   • 调用云存储SDK的putObject方法上传，获取文件的公开访问URL。
   • 将URL存入数据库的image_urls字段（可存JSON数组）。
4. 优势：图片由CDN加速，减轻自身服务器压力，存储空间无限扩展。

5.2 引入缓存提升性能

对于变化不频繁但访问频繁的数据，如厨房列表、热门厨房、系统公告等，可以引入Redis作为缓存。

Spring Cache抽象集成：

1. 添加依赖：spring-boot-starter-data-redis（如果非SpringBoot项目，需手动整合spring-data-redis和jedis/lettuce）。
2. 配置Redis连接。
3. 在Spring配置中启用缓存注解：<cache:annotation-driven />。
4. 在Service方法上使用注解：

   @Service public class KitchenServiceImpl implements KitchenService { @Cacheable(value = "kitchenList", key = "'all'") // 缓存键为 `kitchenList::all` @Override public List<Kitchen> getAllKitchens() { // 这里是查询数据库的耗时操作 return kitchenMapper.selectAll(); } @CacheEvict(value = "kitchenList", key = "'all'") // 当有厨房信息更新时，清除缓存 @Override public void updateKitchen(Kitchen kitchen) { kitchenMapper.update(kitchen); } }

这样，第一次调用getAllKitchens()会查询数据库并将结果存入Redis，后续调用直接从Redis返回，速度极快。当数据更新时，通过@CacheEvict清除缓存，保证下次读取到最新数据。

5.3 编写项目文档与部署手册

一个完整的毕业设计，除了代码，清晰的文档至关重要。这体现了你的工程素养。

1. 项目说明文档（README.md）：

• 项目简介：一两句话说明项目是做什么的。
• 技术栈：列出使用的技术及版本（如Java 8, Spring 4.3.18, MyBatis 3.5.6, MySQL 5.7, Tomcat 8.5）。
• 功能模块：用列表或图表形式展示系统包含的功能。
• 快速开始：
  • 克隆代码：git clone ...
  • 导入数据库：提供sql/shared_kitchen.sql文件。
  • 修改配置：指明jdbc.properties等配置文件的位置和需要修改的内容（数据库连接、Redis地址等）。
  • 构建与运行：mvn clean package，将target/*.war拷贝到Tomcat的webapps下。
• 项目结构：简要说明主要目录的作用（src/main/java,src/main/resources,webapp等）。

2. 数据库设计文档： 可以是一个单独的.md文件或直接写在README里。应包含每张表的字段说明（字段名、类型、是否为空、默认值、注释），以及主要的表关系图（可以用文字描述，如“订单表t_order通过user_id外键关联用户表t_user”）。

3. 部署手册： 详细说明在生产环境（如一台云服务器）上部署的每一步：

• 服务器环境准备：安装JDK、MySQL、Redis、Tomcat/Nginx。
• 防火墙端口开放（80, 443, 3306, 6379等）。
• 项目配置修改详解。
• Tomcat服务配置与开机自启。
• （可选）使用Nginx做反向代理和静态资源服务。
• 域名绑定与SSL证书配置（HTTPS）。

把这些文档写好，不仅方便答辩老师查看，也是你个人能力的一次很好的展示。整个项目从选题、设计、编码、测试到文档，形成了一个完整的闭环，这才是合格的软件工程实践。

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