简介这份PDF是JavaEE课程设计报告书面向高校计算机相关专业学生及需要完成Web开发课程设计的自学者围绕网上订餐系统的完整开发过程展开。报告以Struts、Spring、Hibernate等JavaEE框架为技术主线涵盖需求分析、系统总体设计、流程设计、数据库设计与功能实现等环节可作为课程设计选题参考与答辩材料模板。资源包共1个PDF文件约985KB内容为完整的报告书正文包含系统功能框图、流程图及菜品信息表、管理员信息表、用户注册信息表等数据库表结构说明并涉及登录界面、异常处理机制等实现细节。目前已有723人学习浏览适合需要借鉴系统分析思路、数据库字段设计及JavaEE分层开发流程的读者参考也可用于理解从需求到实现的完整项目文档组织方式。1. 订餐系统 JavaEE 课程设计从“能跑就行”到“敢写进报告书”的分水岭很多同学做订餐系统 JavaEE 课程设计最后卡住的地方不是功能写不出来而是报告书里写不清楚“为什么这么设计”。代码能跑答辩一问就露馅为什么用三层架构而不是 MVC 一把梭数据库表为什么这么拆订单状态流转为什么用枚举而不是字符串这些问题答不上来报告书就只是一份操作说明书拿不到高分。这个标题指向的是一份完整的课程设计交付物一个基于 JavaEE 技术栈的订餐系统外加一份能支撑答辩的技术报告。它解决的核心问题是——让你在有限时间内用主流且不过时的技术组合做出一个结构清晰、可演示、可讲清楚设计决策的系统。适合正在做 Java 课程设计、软件工程课程设计、数据库课程设计的学生也适合想用一个小型项目串联 JavaEE 知识点的自学者。我见过太多人把订餐系统做成“能登录、能点菜、能下单”就收工结果报告书里全是截图和 CRUD 描述。真正拉开差距的是订单状态机、库存扣减时机、前后端数据一致性这些细节。下面按实际开发顺序把选型、建表、核心逻辑、避坑点逐一拆开。2. 技术选型与工程骨架为什么是 Spring Boot MyBatis 而不是纯 Servlet2.1 课程设计场景下的技术栈取舍JavaEE 课程设计最容易翻车的地方是技术栈选得太老或太新。纯 Servlet JSP 能体现“JavaEE 原生”但代码量大、配置繁琐报告书里写出来也显得落后。Spring Boot MyBatis Thymeleaf 或前后端分离是目前大多数院校默认接受且企业也在用的组合。我一般会这样定后端 Spring Boot 2.7.xJava 8 或 11 都兼容持久层 MyBatis-Plus 或原生 MyBatis数据库 MySQL 8.0前端用 Vue 3 Element Plus 或 Thymeleaf 服务端渲染。如果学校要求必须体现 EJB、JSP 等传统 JavaEE 组件那就用 Servlet JSP JDBC 做一版但报告书里要额外说明“教学要求下的技术选型”。提示选型一旦确定报告书第一章就要写清楚“为什么选它”而不是只写“使用了什么”。答辩老师最反感的是“因为网上教程都用这个”。工程骨架用 Maven 多模块或单模块都行。单模块结构简单适合课程设计周期多模块能体现分层但配置成本高。我建议单模块 包分层com.example.ordering ├── controller ├── service │ └── impl ├── mapper ├── entity ├── dto ├── vo ├── config └── common这个结构在报告书里可以直接画成架构图说明“控制层只做参数校验和路由业务逻辑在 Service数据访问在 Mapper”。2.2 用 Spring Initializr 生成可运行的最小工程不要手动建工程直接用 start.spring.io 生成。依赖勾选Spring Web、MyBatis Framework、MySQL Driver、Lombok。如果要用 Thymeleaf 就再加 Thymeleaf。生成后先改application.ymlserver: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/ordering?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: your_password driver-class-name: com.mysql.cj.jdbc.Driver mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.example.ordering.entity configuration: map-underscore-to-camel-case: truemap-underscore-to-camel-case必须开否则数据库的create_time映射不到 Java 的createTime这是血泪经验。serverTimezone不写会报时区错误MySQL 8 尤其明显。启动类上加MapperScan(com.example.ordering.mapper)否则 Mapper 接口注入失败。先写一个/ping接口测试工程能否跑通RestController public class PingController { GetMapping(/ping) public String ping() { return pong; } }浏览器访问localhost:8080/ping返回 pong说明骨架通了。这一步看似简单但很多人跳过后面出问题分不清是配置还是代码。2.3 报告书里怎么描述工程结构报告书不要贴整个 pom.xml只贴关键依赖和版本。用表格列出“技术 / 版本 / 用途”技术版本用途Spring Boot2.7.18容器与自动配置MyBatis3.5.xORM 映射MySQL8.0数据存储Lombok1.18.x简化实体类然后配一段文字说明“为什么不用 JPA”JPA 自动建表方便但课程设计需要手写 SQL 体现数据库设计能力MyBatis 的 XML 映射更适合展示表关系。这个理由答辩时很管用。3. 数据库设计与订单状态机五张表撑起整个订餐流程3.1 从业务动作反推表结构订餐系统的核心动作用户浏览菜品 → 加入购物车 → 提交订单 → 支付 → 商家接单 → 配送 → 完成。每个动作对应数据状态变化。表不用多五张核心表就够user用户表区分普通用户和管理员dish菜品表含分类、价格、库存、图片cart购物车表用户 ID 菜品 ID 数量orders订单主表含订单号、用户 ID、总价、状态、地址、时间order_item订单明细表订单 ID 菜品 ID 数量 下单时单价注意order_item里必须存“下单时单价”不能只存菜品 ID 去关联查价格。菜品价格会变订单历史价格不能变。这是数据库课程设计里常考的点。建表 SQL 示例CREATE TABLE orders ( id BIGINT NOT NULL AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL COMMENT 订单号, user_id BIGINT NOT NULL, total_amount DECIMAL(10,2) NOT NULL, status TINYINT NOT NULL DEFAULT 0 COMMENT 0待支付 1已支付 2配送中 3已完成 4已取消, address VARCHAR(255) NOT NULL, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no), KEY idx_user_id (user_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;status用 TINYINT 而不是 VARCHAR报告书里可以写“用整型枚举减少存储空间并便于索引”。order_no加唯一索引防止重复提交生成相同订单号。3.2 订单状态流转的代码实现状态不能随便改。我一般用一个枚举类加状态机校验public enum OrderStatus { UNPAID(0, 待支付), PAID(1, 已支付), DELIVERING(2, 配送中), COMPLETED(3, 已完成), CANCELLED(4, 已取消); private final int code; private final String desc; OrderStatus(int code, String desc) { this.code code; this.desc desc; } public static boolean canTransfer(int from, int to) { if (from UNPAID.code (to PAID.code || to CANCELLED.code)) return true; if (from PAID.code to DELIVERING.code) return true; if (from DELIVERING.code to COMPLETED.code) return true; return false; } // getter 省略 }Service 层更新状态前先调canTransfer不合法就抛业务异常。这样报告书里可以画一张状态流转图说明“系统不允许从待支付直接跳到已完成”。3.3 库存扣减的时机与 SQL 写法库存扣减有两个时机加购物车时扣或提交订单时扣。我选提交订单时扣因为购物车可能长期不结算提前扣会导致库存被占死。扣减 SQL 必须带条件防止超卖UPDATE dish SET stock stock - #{quantity} WHERE id #{dishId} AND stock #{quantity}返回影响行数为 0 就说明库存不足抛异常回滚事务。Service 方法上加Transactional确保订单主表、明细表、库存更新在同一个事务里。注意不要先查库存再更新并发下会超卖。直接UPDATE ... WHERE stock ?是唯一可靠做法。报告书里把这段 SQL 和事务注解一起贴出来说明“利用数据库行锁保证库存一致性”比写一堆文字都有说服力。4. 核心业务代码落地从购物车到订单提交的完整链路4.1 购物车模块的接口与实现购物车接口设计POST /cart/add加菜品参数 dishId、quantityGET /cart/list当前用户购物车列表POST /cart/update改数量DELETE /cart/remove/{dishId}删除Controller 里从 Session 或 Token 拿 userId不要从前端传否则越权。Service 实现加菜品时先查是否已存在存在就累加数量public void addToCart(Long userId, Long dishId, Integer quantity) { Cart exist cartMapper.selectByUserAndDish(userId, dishId); if (exist ! null) { cartMapper.updateQuantity(exist.getId(), exist.getQuantity() quantity); } else { Cart cart new Cart(); cart.setUserId(userId); cart.setDishId(dishId); cart.setQuantity(quantity); cartMapper.insert(cart); } }这段逻辑简单但报告书里要写清楚“为什么用累加而不是覆盖”——因为用户可能多次点击加购覆盖会丢失之前的选择。4.2 订单提交的事务与订单号生成提交订单是核心链路步骤查购物车 → 校验库存 → 扣库存 → 生成订单主表 → 生成明细 → 清空购物车。全部在一个Transactional方法里。订单号生成用时间戳 用户 ID 后四位 随机数public String generateOrderNo(Long userId) { String time LocalDateTime.now().format(DateTimeFormatter.ofPattern(yyyyMMddHHmmss)); String uid String.format(%04d, userId % 10000); String rand String.valueOf((int)(Math.random() * 9000) 1000); return time uid rand; }不要用 UUID太长且无序不利于数据库索引。时间戳前缀保证大致有序插入性能更好。提交订单代码骨架Transactional(rollbackFor Exception.class) public OrderVO submitOrder(Long userId, String address) { ListCart cartList cartMapper.selectByUserId(userId); if (cartList.isEmpty()) throw new BizException(购物车为空); BigDecimal total BigDecimal.ZERO; ListOrderItem items new ArrayList(); for (Cart cart : cartList) { int affected dishMapper.reduceStock(cart.getDishId(), cart.getQuantity()); if (affected 0) throw new BizException(库存不足); Dish dish dishMapper.selectById(cart.getDishId()); total total.add(dish.getPrice().multiply(BigDecimal.valueOf(cart.getQuantity()))); // 构建 OrderItem... } // 插入 orders 和 order_item清空 cart return orderVO; }rollbackFor Exception.class必须写否则受检异常不回滚。这是踩坑重灾区。4.3 报告书里怎么呈现核心代码不要贴整个 Service 类。挑三个片段库存扣减 SQL、订单号生成方法、事务注解的方法签名。每个片段配一段“设计意图”说明。比如库存扣减那里写“采用条件更新而非先查后改避免并发超卖利用 InnoDB 行锁保证原子性。”这样老师一看就知道你懂原理不是抄的。5. 避坑与排查课程设计里最容易翻车的五个点5.1 中文乱码从数据库到前端全链路排查现象菜品名称在页面显示问号或提交后数据库存成乱码。原因数据库字符集不是 utf8mb4或连接 URL 没加 characterEncoding或 Tomcat 编码配置缺失。解决建库时CREATE DATABASE ordering DEFAULT CHARSET utf8mb4 COLLATE utf8mb4_unicode_ci;JDBC URL 加useUnicodetruecharacterEncodingutf8Spring Boot 的server.servlet.encoding.charsetUTF-8和forcetrue都配上。三层都对了才不会乱码。5.2 事务不生效方法内部调用是黑匣子现象库存扣了订单没生成数据不一致。原因Transactional方法被同一个类里的另一个方法直接调用不走代理事务不生效。解决把事务方法放到独立的 Service 类或通过注入自身代理调用。报告书里可以写“Spring AOP 代理机制导致自调用失效”这是加分项。5.3 前端传 userId 导致越权现象改一下请求参数就能看到别人的购物车和订单。原因Controller 直接用了前端传的 userId没有从登录态取。解决登录成功后把 userId 存 Session 或 JWT所有需要用户身份的接口从 Session/JWT 解析绝不信任前端传值。这是安全底线答辩必问。5.4 MyBatis 映射失败字段名对不上现象查询返回对象属性全是 null但 SQL 在数据库能查到数据。原因数据库create_time和 JavacreateTime没映射或map-underscore-to-camel-case没开。解决检查 yml 配置或手动在 XML 里写result columncreate_time propertycreateTime/。我一般两个都做双保险。5.5 订单重复提交用户连点两下生成两单现象同一个用户同一时间生成两笔相同订单。原因前端没防抖后端没幂等。解决前端按钮点击后置灰后端用 Redis 或数据库唯一索引防重。课程设计里简单做法提交前先查该用户是否有“待支付”订单且金额相同有就拒绝。或者用order_no唯一索引重复插入报错后捕获返回“请勿重复提交”。6. 报告书写作技巧把代码翻译成设计语言6.1 架构图与流程图的画法报告书里不要只贴代码。用 draw.io 或 ProcessOn 画三张图系统架构图浏览器 → Controller → Service → Mapper → MySQL、订单状态流转图五个状态和箭头、核心业务时序图提交订单的调用链。每张图下面配 100 字说明讲清楚“为什么这样分层”“为什么状态只能单向流转”。架构图里把包名标上和代码结构对应。时序图里标出事务边界说明“从扣库存到写订单在一个事务内”。这些图比文字更能体现设计能力。6.2 测试用例表格的写法不要写“我测试了登录功能正常”。用表格列测试项、输入、预期输出、实际输出、是否通过测试项输入预期实际结果库存不足下单库存 1下单 2提示库存不足提示库存不足通过重复提交连续点击提交两次只生成一单只生成一单通过越权查订单用户 A 查用户 B 订单返回空或 403返回空通过至少写 10 条覆盖正常和异常。异常用例是拉开分差的地方。6.3 我踩过的坑与最后习惯我做过三次订餐系统课程设计前两次都栽在“以为简单所以没写测试”。第三次我强迫自己每写完一个 Service 方法就先写一个 JUnit 测试或 Postman 请求确认通过再写下一个。结果那次报告书里的测试章节最厚答辩老师问“你怎么保证库存不超卖”我直接翻到测试用例那一页指着并发测试的记录说“我模拟了 10 个线程同时下单库存 5 最终只成功 5 单”。老师没再追问。另一个习惯所有状态码、枚举值、错误提示统一放在一个constants类或枚举里不要散落在各处。报告书里写“统一常量管理便于维护和扩展”这是软件工程课程设计明确要求的。如果你正在做这个题目先把五张表建好把订单状态机写出来再回头补报告书。代码跑通了报告书自然有东西写。希望帮到你。本文还有配套的精品资源点击获取 JavaEE订餐系统课程设计：Spring Boot+MyBatis实现与报告书写作指南
简介这份PDF是JavaEE课程设计报告书面向高校计算机相关专业学生及需要完成Web开发课程设计的自学者围绕网上订餐系统的完整开发过程展开。报告以Struts、Spring、Hibernate等JavaEE框架为技术主线涵盖需求分析、系统总体设计、流程设计、数据库设计与功能实现等环节可作为课程设计选题参考与答辩材料模板。资源包共1个PDF文件约985KB内容为完整的报告书正文包含系统功能框图、流程图及菜品信息表、管理员信息表、用户注册信息表等数据库表结构说明并涉及登录界面、异常处理机制等实现细节。目前已有723人学习浏览适合需要借鉴系统分析思路、数据库字段设计及JavaEE分层开发流程的读者参考也可用于理解从需求到实现的完整项目文档组织方式。1. 订餐系统 JavaEE 课程设计从“能跑就行”到“敢写进报告书”的分水岭很多同学做订餐系统 JavaEE 课程设计最后卡住的地方不是功能写不出来而是报告书里写不清楚“为什么这么设计”。代码能跑答辩一问就露馅为什么用三层架构而不是 MVC 一把梭数据库表为什么这么拆订单状态流转为什么用枚举而不是字符串这些问题答不上来报告书就只是一份操作说明书拿不到高分。这个标题指向的是一份完整的课程设计交付物一个基于 JavaEE 技术栈的订餐系统外加一份能支撑答辩的技术报告。它解决的核心问题是——让你在有限时间内用主流且不过时的技术组合做出一个结构清晰、可演示、可讲清楚设计决策的系统。适合正在做 Java 课程设计、软件工程课程设计、数据库课程设计的学生也适合想用一个小型项目串联 JavaEE 知识点的自学者。我见过太多人把订餐系统做成“能登录、能点菜、能下单”就收工结果报告书里全是截图和 CRUD 描述。真正拉开差距的是订单状态机、库存扣减时机、前后端数据一致性这些细节。下面按实际开发顺序把选型、建表、核心逻辑、避坑点逐一拆开。2. 技术选型与工程骨架为什么是 Spring Boot MyBatis 而不是纯 Servlet2.1 课程设计场景下的技术栈取舍JavaEE 课程设计最容易翻车的地方是技术栈选得太老或太新。纯 Servlet JSP 能体现“JavaEE 原生”但代码量大、配置繁琐报告书里写出来也显得落后。Spring Boot MyBatis Thymeleaf 或前后端分离是目前大多数院校默认接受且企业也在用的组合。我一般会这样定后端 Spring Boot 2.7.xJava 8 或 11 都兼容持久层 MyBatis-Plus 或原生 MyBatis数据库 MySQL 8.0前端用 Vue 3 Element Plus 或 Thymeleaf 服务端渲染。如果学校要求必须体现 EJB、JSP 等传统 JavaEE 组件那就用 Servlet JSP JDBC 做一版但报告书里要额外说明“教学要求下的技术选型”。提示选型一旦确定报告书第一章就要写清楚“为什么选它”而不是只写“使用了什么”。答辩老师最反感的是“因为网上教程都用这个”。工程骨架用 Maven 多模块或单模块都行。单模块结构简单适合课程设计周期多模块能体现分层但配置成本高。我建议单模块 包分层com.example.ordering ├── controller ├── service │ └── impl ├── mapper ├── entity ├── dto ├── vo ├── config └── common这个结构在报告书里可以直接画成架构图说明“控制层只做参数校验和路由业务逻辑在 Service数据访问在 Mapper”。2.2 用 Spring Initializr 生成可运行的最小工程不要手动建工程直接用 start.spring.io 生成。依赖勾选Spring Web、MyBatis Framework、MySQL Driver、Lombok。如果要用 Thymeleaf 就再加 Thymeleaf。生成后先改application.ymlserver: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/ordering?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: your_password driver-class-name: com.mysql.cj.jdbc.Driver mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.example.ordering.entity configuration: map-underscore-to-camel-case: truemap-underscore-to-camel-case必须开否则数据库的create_time映射不到 Java 的createTime这是血泪经验。serverTimezone不写会报时区错误MySQL 8 尤其明显。启动类上加MapperScan(com.example.ordering.mapper)否则 Mapper 接口注入失败。先写一个/ping接口测试工程能否跑通RestController public class PingController { GetMapping(/ping) public String ping() { return pong; } }浏览器访问localhost:8080/ping返回 pong说明骨架通了。这一步看似简单但很多人跳过后面出问题分不清是配置还是代码。2.3 报告书里怎么描述工程结构报告书不要贴整个 pom.xml只贴关键依赖和版本。用表格列出“技术 / 版本 / 用途”技术版本用途Spring Boot2.7.18容器与自动配置MyBatis3.5.xORM 映射MySQL8.0数据存储Lombok1.18.x简化实体类然后配一段文字说明“为什么不用 JPA”JPA 自动建表方便但课程设计需要手写 SQL 体现数据库设计能力MyBatis 的 XML 映射更适合展示表关系。这个理由答辩时很管用。3. 数据库设计与订单状态机五张表撑起整个订餐流程3.1 从业务动作反推表结构订餐系统的核心动作用户浏览菜品 → 加入购物车 → 提交订单 → 支付 → 商家接单 → 配送 → 完成。每个动作对应数据状态变化。表不用多五张核心表就够user用户表区分普通用户和管理员dish菜品表含分类、价格、库存、图片cart购物车表用户 ID 菜品 ID 数量orders订单主表含订单号、用户 ID、总价、状态、地址、时间order_item订单明细表订单 ID 菜品 ID 数量 下单时单价注意order_item里必须存“下单时单价”不能只存菜品 ID 去关联查价格。菜品价格会变订单历史价格不能变。这是数据库课程设计里常考的点。建表 SQL 示例CREATE TABLE orders ( id BIGINT NOT NULL AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL COMMENT 订单号, user_id BIGINT NOT NULL, total_amount DECIMAL(10,2) NOT NULL, status TINYINT NOT NULL DEFAULT 0 COMMENT 0待支付 1已支付 2配送中 3已完成 4已取消, address VARCHAR(255) NOT NULL, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no), KEY idx_user_id (user_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;status用 TINYINT 而不是 VARCHAR报告书里可以写“用整型枚举减少存储空间并便于索引”。order_no加唯一索引防止重复提交生成相同订单号。3.2 订单状态流转的代码实现状态不能随便改。我一般用一个枚举类加状态机校验public enum OrderStatus { UNPAID(0, 待支付), PAID(1, 已支付), DELIVERING(2, 配送中), COMPLETED(3, 已完成), CANCELLED(4, 已取消); private final int code; private final String desc; OrderStatus(int code, String desc) { this.code code; this.desc desc; } public static boolean canTransfer(int from, int to) { if (from UNPAID.code (to PAID.code || to CANCELLED.code)) return true; if (from PAID.code to DELIVERING.code) return true; if (from DELIVERING.code to COMPLETED.code) return true; return false; } // getter 省略 }Service 层更新状态前先调canTransfer不合法就抛业务异常。这样报告书里可以画一张状态流转图说明“系统不允许从待支付直接跳到已完成”。3.3 库存扣减的时机与 SQL 写法库存扣减有两个时机加购物车时扣或提交订单时扣。我选提交订单时扣因为购物车可能长期不结算提前扣会导致库存被占死。扣减 SQL 必须带条件防止超卖UPDATE dish SET stock stock - #{quantity} WHERE id #{dishId} AND stock #{quantity}返回影响行数为 0 就说明库存不足抛异常回滚事务。Service 方法上加Transactional确保订单主表、明细表、库存更新在同一个事务里。注意不要先查库存再更新并发下会超卖。直接UPDATE ... WHERE stock ?是唯一可靠做法。报告书里把这段 SQL 和事务注解一起贴出来说明“利用数据库行锁保证库存一致性”比写一堆文字都有说服力。4. 核心业务代码落地从购物车到订单提交的完整链路4.1 购物车模块的接口与实现购物车接口设计POST /cart/add加菜品参数 dishId、quantityGET /cart/list当前用户购物车列表POST /cart/update改数量DELETE /cart/remove/{dishId}删除Controller 里从 Session 或 Token 拿 userId不要从前端传否则越权。Service 实现加菜品时先查是否已存在存在就累加数量public void addToCart(Long userId, Long dishId, Integer quantity) { Cart exist cartMapper.selectByUserAndDish(userId, dishId); if (exist ! null) { cartMapper.updateQuantity(exist.getId(), exist.getQuantity() quantity); } else { Cart cart new Cart(); cart.setUserId(userId); cart.setDishId(dishId); cart.setQuantity(quantity); cartMapper.insert(cart); } }这段逻辑简单但报告书里要写清楚“为什么用累加而不是覆盖”——因为用户可能多次点击加购覆盖会丢失之前的选择。4.2 订单提交的事务与订单号生成提交订单是核心链路步骤查购物车 → 校验库存 → 扣库存 → 生成订单主表 → 生成明细 → 清空购物车。全部在一个Transactional方法里。订单号生成用时间戳 用户 ID 后四位 随机数public String generateOrderNo(Long userId) { String time LocalDateTime.now().format(DateTimeFormatter.ofPattern(yyyyMMddHHmmss)); String uid String.format(%04d, userId % 10000); String rand String.valueOf((int)(Math.random() * 9000) 1000); return time uid rand; }不要用 UUID太长且无序不利于数据库索引。时间戳前缀保证大致有序插入性能更好。提交订单代码骨架Transactional(rollbackFor Exception.class) public OrderVO submitOrder(Long userId, String address) { ListCart cartList cartMapper.selectByUserId(userId); if (cartList.isEmpty()) throw new BizException(购物车为空); BigDecimal total BigDecimal.ZERO; ListOrderItem items new ArrayList(); for (Cart cart : cartList) { int affected dishMapper.reduceStock(cart.getDishId(), cart.getQuantity()); if (affected 0) throw new BizException(库存不足); Dish dish dishMapper.selectById(cart.getDishId()); total total.add(dish.getPrice().multiply(BigDecimal.valueOf(cart.getQuantity()))); // 构建 OrderItem... } // 插入 orders 和 order_item清空 cart return orderVO; }rollbackFor Exception.class必须写否则受检异常不回滚。这是踩坑重灾区。4.3 报告书里怎么呈现核心代码不要贴整个 Service 类。挑三个片段库存扣减 SQL、订单号生成方法、事务注解的方法签名。每个片段配一段“设计意图”说明。比如库存扣减那里写“采用条件更新而非先查后改避免并发超卖利用 InnoDB 行锁保证原子性。”这样老师一看就知道你懂原理不是抄的。5. 避坑与排查课程设计里最容易翻车的五个点5.1 中文乱码从数据库到前端全链路排查现象菜品名称在页面显示问号或提交后数据库存成乱码。原因数据库字符集不是 utf8mb4或连接 URL 没加 characterEncoding或 Tomcat 编码配置缺失。解决建库时CREATE DATABASE ordering DEFAULT CHARSET utf8mb4 COLLATE utf8mb4_unicode_ci;JDBC URL 加useUnicodetruecharacterEncodingutf8Spring Boot 的server.servlet.encoding.charsetUTF-8和forcetrue都配上。三层都对了才不会乱码。5.2 事务不生效方法内部调用是黑匣子现象库存扣了订单没生成数据不一致。原因Transactional方法被同一个类里的另一个方法直接调用不走代理事务不生效。解决把事务方法放到独立的 Service 类或通过注入自身代理调用。报告书里可以写“Spring AOP 代理机制导致自调用失效”这是加分项。5.3 前端传 userId 导致越权现象改一下请求参数就能看到别人的购物车和订单。原因Controller 直接用了前端传的 userId没有从登录态取。解决登录成功后把 userId 存 Session 或 JWT所有需要用户身份的接口从 Session/JWT 解析绝不信任前端传值。这是安全底线答辩必问。5.4 MyBatis 映射失败字段名对不上现象查询返回对象属性全是 null但 SQL 在数据库能查到数据。原因数据库create_time和 JavacreateTime没映射或map-underscore-to-camel-case没开。解决检查 yml 配置或手动在 XML 里写result columncreate_time propertycreateTime/。我一般两个都做双保险。5.5 订单重复提交用户连点两下生成两单现象同一个用户同一时间生成两笔相同订单。原因前端没防抖后端没幂等。解决前端按钮点击后置灰后端用 Redis 或数据库唯一索引防重。课程设计里简单做法提交前先查该用户是否有“待支付”订单且金额相同有就拒绝。或者用order_no唯一索引重复插入报错后捕获返回“请勿重复提交”。6. 报告书写作技巧把代码翻译成设计语言6.1 架构图与流程图的画法报告书里不要只贴代码。用 draw.io 或 ProcessOn 画三张图系统架构图浏览器 → Controller → Service → Mapper → MySQL、订单状态流转图五个状态和箭头、核心业务时序图提交订单的调用链。每张图下面配 100 字说明讲清楚“为什么这样分层”“为什么状态只能单向流转”。架构图里把包名标上和代码结构对应。时序图里标出事务边界说明“从扣库存到写订单在一个事务内”。这些图比文字更能体现设计能力。6.2 测试用例表格的写法不要写“我测试了登录功能正常”。用表格列测试项、输入、预期输出、实际输出、是否通过测试项输入预期实际结果库存不足下单库存 1下单 2提示库存不足提示库存不足通过重复提交连续点击提交两次只生成一单只生成一单通过越权查订单用户 A 查用户 B 订单返回空或 403返回空通过至少写 10 条覆盖正常和异常。异常用例是拉开分差的地方。6.3 我踩过的坑与最后习惯我做过三次订餐系统课程设计前两次都栽在“以为简单所以没写测试”。第三次我强迫自己每写完一个 Service 方法就先写一个 JUnit 测试或 Postman 请求确认通过再写下一个。结果那次报告书里的测试章节最厚答辩老师问“你怎么保证库存不超卖”我直接翻到测试用例那一页指着并发测试的记录说“我模拟了 10 个线程同时下单库存 5 最终只成功 5 单”。老师没再追问。另一个习惯所有状态码、枚举值、错误提示统一放在一个constants类或枚举里不要散落在各处。报告书里写“统一常量管理便于维护和扩展”这是软件工程课程设计明确要求的。如果你正在做这个题目先把五张表建好把订单状态机写出来再回头补报告书。代码跑通了报告书自然有东西写。希望帮到你。本文还有配套的精品资源点击获取