企业官网建设流程全解析

简介：这是一份基于SpringBoot的校园外卖系统设计实现类毕业论文，适合计算机相关专业学生、毕业设计写作者及需要快速梳理外卖系统开发思路的开发者参考，重点解决从需求分析、业务建模、技术选型到系统测试与部署的一体化参考需求。文档基于Java语言与SpringBoot框架，前端采用Vue.js，并通过Spring Security实现安全控制、Spring Data JPA与MySQL完成数据持久化；内容详细划分了用户端、商家端和管理员端功能，并结合表现层、业务逻辑层、数据访问层和数据持久层的分层架构，给出了订单处理、商品管理、数据统计等核心模块的设计要点。资源包内仅含1个doc格式的毕业论文文件，包体大小约9.28MB，正文包括中英文摘要、目录、选题背景、国内外研究现状、开发工具介绍、数据库设计、功能测试和总结展望等章节，结构完整、层次清晰。已有29人学习下载，可作为同类系统毕业论文的模板参考，也能帮助开发者快速掌握基于SpringBoot的外卖系统设计思路，并用于实际项目文档的整理与毕业设计撰写。

1. 基于SpringBoot的校园外卖系统：这不是点餐软件，而是一套订单状态机

毕设季 Java 方向的高频选题里，「基于SpringBoot的校园外卖系统的设计与实现」几乎每年都有人做，但大多数版本都倒在同一处：CRUD 写完了，系统却不像「外卖系统」，更像一个商品管理后台。真正让这个题目成立的核心，是订单从下单到送达的完整状态流转，加上学生、商家、骑手、管理员四类角色的权限边界。很多人把这个题做浅了，等到写论文才发现没有东西可以写。

这篇笔记按我一般会采用的方案，从状态机设计、数据库建表、SpringBoot 核心链路到论文成稿，把整条路径拆开讲透，每个环节都给出能直接抄的参数和代码，也会把最容易翻车的几个点提前标出来。正为选题发愁、或者已经立项但不确定先写代码还是先写论文的同学，按这条路径走完，代码和论文都会顺手很多。

2. 先从建表和状态设计下手：校园外卖的四个角色与订单流转

2.1 四个角色与一条订单的完整状态机

一个校园外卖系统至少要有四个入口：学生用户负责浏览商品、下单支付和确认收货；商家负责接单、备餐和出餐；骑手负责抢单和配送；管理员负责商家审核、骑手管理和订单仲裁。如果只用一张表加一个 role 字段区分身份，那只能叫「登录系统」，不叫外卖系统。真正拉开差距的是订单状态机的设计，它决定了后端怎么写、数据库怎么查、前端按钮怎么显示。

我一般把订单状态定义为：待支付(0)、已支付待接单(1)、商家已接单备餐中(2)、骑手配送中(3)、已完成(4)，另有已取消(5)和退款中(6)。每次状态变更不是简单地把 status 字段改成一个新数字，而是要从当前状态、执行角色、动作三个维度同时校验，满足条件才允许跳转。这样设计之后，前端传入的「状态」永远只是期望值，真正的状态以数据库当前值为准，后面所有并发问题都能少一半。

下面这张状态流转表建议直接贴进论文第四章，它比大段文字更能说明工作量：

状态机定完之后，后端 service 层的写法就固定了：先按订单号查出当前状态，再和期望状态比对，最后用带条件的 UPDATE 做状态变更，而不是直接 updateById。这个过程是整篇论文「系统设计」章节的骨架，代码写对了，论文里只需要把这张表展开成文字。

2.2 数据库设计：八张核心表和三个必须冗余的字段

外卖系统的表结构比普通 CRUD 项目多一层「订单主表 + 订单明细表」的拆分，这是论文里必须写清楚的建模依据。订单主表存一笔订单的总体信息，订单明细表存这笔订单买了哪些商品、每个商品多少钱。明细表必须把商品名称和成交单价冗余进来，因为商家改价或下架商品后，历史订单的明细不能跟着变，否则对账全是乱的。

我一般会建这八张表：user（账号表）、merchant（商家表）、product（商品表）、cart（购物车表）、orders（订单主表）、order_item（订单明细表）、address（收货地址表）、delivery（配送记录表）。其中 user 表用 role 字段区分学生、商家、骑手和管理员，而不是建四张独立的账号表，这样登录鉴权只走一套逻辑。

CREATE TABLE `user` ( `id` bigint NOT NULL AUTO_INCREMENT, `username` varchar(50) NOT NULL COMMENT '登录名', `password` varchar(100) NOT NULL COMMENT 'BCrypt加密后的密码', `role` tinyint NOT NULL DEFAULT 0 COMMENT '0-学生 1-商家 2-骑手 3-管理员', `phone` varchar(20) DEFAULT NULL, `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_username` (`username`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='账号表'; CREATE TABLE `product` ( `id` bigint NOT NULL AUTO_INCREMENT, `merchant_id` bigint NOT NULL COMMENT '所属商家', `name` varchar(100) NOT NULL, `price` decimal(10,2) NOT NULL COMMENT '单价，用DECIMAL不用FLOAT', `stock` int NOT NULL DEFAULT 0, `status` tinyint NOT NULL DEFAULT 1 COMMENT '1-上架 0-下架', PRIMARY KEY (`id`), KEY `idx_merchant` (`merchant_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='商品表'; CREATE TABLE `orders` ( `id` bigint NOT NULL AUTO_INCREMENT, `order_no` varchar(32) NOT NULL COMMENT '业务流水号，展示给用户', `user_id` bigint NOT NULL, `merchant_id` bigint NOT NULL, `total_amount` decimal(10,2) NOT NULL, `status` tinyint NOT NULL DEFAULT 0 COMMENT '0-待支付 1-待接单 2-备餐中 3-配送中 4-已完成 5-已取消', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_order_no` (`order_no`), KEY `idx_user_status` (`user_id`, `status`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='订单主表'; CREATE TABLE `order_item` ( `id` bigint NOT NULL AUTO_INCREMENT, `order_id` bigint NOT NULL, `product_id` bigint NOT NULL, `product_name` varchar(100) NOT NULL COMMENT '商品名称快照', `price` decimal(10,2) NOT NULL COMMENT '成交单价快照', `count` int NOT NULL, PRIMARY KEY (`id`), KEY `idx_order` (`order_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='订单明细表';

金额字段用 DECIMAL(10,2) 而不是 FLOAT，是这类系统里最基础但论文必问的一点：浮点数在累加和比较时存在精度误差，对账会差几分钱；DECIMAL 是精确小数，配合 BigDecimal 计算不会出现 0.1 + 0.2 不等于 0.3 的问题。order_no 用独立字段而不是直接暴露自增 id，是为了在客服排查、骑手对单时有一串可读的流水号，生成规则一般就是「业务前缀 + 时间戳 + 随机数」。

2.3 为什么偏偏是 SpringBoot + MyBatis：选型理由要在答辩前讲顺

毕设答辩几乎必问「为什么选 SpringBoot」，这个问题不能只回答「因为简单」。SpringBoot 的核心是自动装配：@SpringBootApplication 上的 @EnableAutoConfiguration 会读取 META-INF 下的自动配置类，按 @ConditionalOnClass、@ConditionalOnMissingBean 等条件判断当前 classpath 有没有对应依赖，有就自动创建 DataSource、SqlSessionFactory 这类 Bean。这就是为什么只要引入 spring-boot-starter-web，项目就能直接跑起来，不用像 SSM 那样手写一堆 XML 配置。

持久层我倾向 MyBatis 而不是 JPA，原因很实际：外卖系统的订单查询有大量动态条件（按状态、按时间段、按商家统计），MyBatis 的 XML 里可以直接写动态 SQL，一个统计报表一条 SQL 就能查完；JPA 在这种场景下要么写 @Query 注解，要么频繁拼接 Specification，远不如 XML 直观。配合 MyBatis 的驼峰映射 map-underscore-to-camel-case=true，数据库字段 create_time 直接映射到实体属性 createTime，省掉一大半 resultMap。项目结构按 controller → service → mapper 三层走，controller 只做参数接收和结果封装，service 放业务逻辑和事务，mapper 只碰 SQL，这个分层本身也是论文「系统设计」章节的现成素材。

3. 用 SpringBoot 把核心链路跑通：登录、下单、接单与定时关单

3.1 项目骨架与配置文件：版本、端口、数据源一次配好

SpringBoot 项目骨架我建议用 start.spring.io 生成，毕设阶段最稳的组合是 Spring Boot 2.7.x + JDK 1.8/11 + MySQL 5.7/8.0。不要一上来就追最新版，网上绝大多数教程和源码都是基于 2.x 写的，遇到问题搜得到、问得着。Spring Boot 3.x 把 javax 命名空间迁到了 jakarta，MyBatis 的 starter、部分拦截器写法全都变了，对毕设来说研习成本不划算。

pom.xml 里关键依赖就这几样：

<parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.7.18</version> </parent> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.mybatis.spring.boot</groupId> <artifactId>mybatis-spring-boot-starter</artifactId> <version>2.3.2</version> </dependency> <dependency> <groupId>com.mysql</groupId> <artifactId>mysql-connector-j</artifactId> <scope>runtime</scope> </dependency> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <optional>true</optional> </dependency> </dependencies>

mybatis-spring-boot-starter 的版本要和 Spring Boot 主版本匹配，2.3.2 对应 Spring Boot 2.7.x，这个组合经过大量项目验证，不会有兼容性意外。Lombok 能省掉实体类的 getter/setter，但注意 IDEA 必须装 Lombok 插件，否则编译期直接认不出 @Data 注解，这是新手最常见的启动失败原因。

application.yml 里最需要注意的是数据源 URL 的编码和时区参数：

server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/campus_order?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver mybatis: mapper-locations: classpath:mapper/*.xml configuration: map-underscore-to-camel-case: true logging: level: com.example.campus.mapper: debug

端口改起来有两个入口：直接改 server.port，或者在 IDEA 的 Run Configuration 里配置启动参数加 --server.port=9090，后者适合临时演示多个端口。mapper-locations 指定 XML 文件位置，扫描不到 XML 时启动不会报错，但所有 mapper 方法在运行时都会抛 BindingException，看到这个异常先检查路径。

3.2 基于 JWT 的登录鉴权：无状态 token 与拦截器配置

毕设外卖系统不需要做单点登录，用 JWT 是最合适的方案：登录成功后后端签发一个 token，前端每次请求放在 Authorization 头里，后端用拦截器统一校验。密码不能明文入库，用 Spring Security 里的 BCryptPasswordEncoder 加密，答辩时提到加密方式比全篇写 MD5 高一个档次。

@Component public class JwtUtil { // 演示用，生产环境应放在配置中心或环境变量 private static final String SECRET = "campus-order-secret-key"; // token 有效期 2 小时，单位毫秒 private static final long EXPIRE = 2 * 60 * 60 * 1000L; public String createToken(Long userId, String role) { return Jwts.builder() .claim("userId", userId) .claim("role", role) .setExpiration(new Date(System.currentTimeMillis() + EXPIRE)) .signWith(SignatureAlgorithm.HS256, SECRET) .compact(); } public Claims parseToken(String token) { return Jwts.parser().setSigningKey(SECRET).parseClaimsJws(token).getBody(); } }

SECRET 硬编码只适合课设和毕设演示，论文里可以补一句「实际部署时应将密钥放入环境变量或配置中心」。token 过期时间我习惯设 2 小时，毕设演示多在半个小时内完成，不用做 refresh token 机制，把这点写进论文反而显得你清楚自己的边界。

@Component public class LoginInterceptor implements HandlerInterceptor { @Autowired private JwtUtil jwtUtil; @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 跨域预检请求直接放行，否则前端拿不到响应 if ("OPTIONS".equalsIgnoreCase(request.getMethod())) { return true; } String token = request.getHeader("Authorization"); if (token == null || !token.startsWith("Bearer ")) { response.setStatus(401); return false; } try { Claims claims = jwtUtil.parseToken(token.substring(7)); request.setAttribute("userId", claims.get("userId")); request.setAttribute("role", claims.get("role")); return true; } catch (Exception e) { response.setStatus(401); return false; } } }

拦截器里从 token 解析出 userId 和 role 放进 request 属性，controller 用 @RequestAttribute 直接取，不用每个接口都重复解析。注意 OPTIONS 请求必须放行，否则前后端联调时浏览器预检直接被 401 挡掉，界面看起来就像「永远登录不进去」。

@Configuration public class WebMvcConfig implements WebMvcConfigurer { @Autowired private LoginInterceptor loginInterceptor; @Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(loginInterceptor) .addPathPatterns("/api/**") .excludePathPatterns( "/api/auth/login", "/api/auth/register", "/api/product/list", "/static/**" ); } }

放行路径要注意：登录、注册、商品列表这些入口必须放行，/static/** 放行是因为后面把 Vue 打包进 SpringBoot 后，静态资源不能拦。之后新增接口时第一反应是问自己「这个接口要不要登录才能调」，避免把全部接口都扔进拦截路径。

3.3 下单接口：事务、乐观锁与库存扣减

下单是外卖系统最核心的接口，也是论文里最能展示深度的一段代码。基本流程是：计算总价、扣减库存、写订单主表、写订单明细表。库存扣减必须解决并发超卖问题，常见做法是用带条件的 UPDATE 做乐观锁，把「查库存、判断、更新」三步压缩成一条 SQL。

@Service public class OrderService { @Autowired private ProductMapper productMapper; @Autowired private OrderMapper orderMapper; @Autowired private OrderItemMapper orderItemMapper; @Transactional(rollbackFor = Exception.class) public Order createOrder(Long userId, Long merchantId, List<CartItem> items) { // 1. 生成业务流水号：前缀 + 时间戳 + 6位随机数 String orderNo = "CO" + System.currentTimeMillis() + String.format("%06d", ThreadLocalRandom.current().nextInt(1000000)); // 2. 计算总金额，用 BigDecimal 累加 BigDecimal total = BigDecimal.ZERO; for (CartItem item : items) { total = total.add(item.getPrice().multiply(BigDecimal.valueOf(item.getCount()))); } // 3. 扣减库存：乐观锁，条件带 stock >= count for (CartItem item : items) { int rows = productMapper.reduceStock(item.getProductId(), item.getCount()); if (rows == 0) { throw new RuntimeException("商品库存不足"); } } // 4. 插入订单主表和明细表 Order order = new Order(); order.setOrderNo(orderNo); order.setUserId(userId); order.setMerchantId(merchantId); order.setTotalAmount(total); order.setStatus(0); orderMapper.insert(order); for (CartItem item : items) { OrderItem oi = new OrderItem(); oi.setOrderId(order.getId()); oi.setProductId(item.getProductId()); oi.setProductName(item.getProductName()); oi.setPrice(item.getPrice()); oi.setCount(item.getCount()); orderItemMapper.insert(oi); } return order; } }

@Transactional(rollbackFor = Exception.class) 表示受检异常也触发回滚，别用默认的只回滚 RuntimeException。订单号用时间戳加随机数，避免直接暴露自增 id 被猜出订单量。金额计算全部走 BigDecimal，单价从购物车带过来时已经在商品查询阶段锁定，这里不做二次查询，减少数据库压力。

<update id="reduceStock"> UPDATE product SET stock = stock - #{count} WHERE id = #{productId} AND stock >= #{count} </update>

这个 UPDATE 是关键：数据库行锁保证同一时刻只有一个请求能成功扣减，返回 0 表示库存不足，直接抛异常让整个事务回滚，订单不会落库。比起「先 select 再 update」的实现，这条路把并发窗口直接关掉了。如果论文里想写深一点，把悲观锁 SELECT ... FOR UPDATE 的写法也列出来对比，说明为什么选择乐观锁，属于加分项。

3.4 SpringBoot 定时任务：超时未支付订单自动关单

外卖订单超过一定时间未支付需要自动取消，并把扣掉的库存回补。这个功能靠人肉点按钮是不现实的，SpringBoot 里直接用 @Scheduled 就能实现，代码量很少但论文里很好展开。

@Component public class OrderTimeoutTask { @Autowired private OrderMapper orderMapper; @Autowired private ProductMapper productMapper; // cron: 秒 分 时 日 月 周，这里表示每5分钟执行一次 @Scheduled(cron = "0 */5 * * * ?") public void closeExpiredOrders() { // 找出超过15分钟未支付的订单 List<Order> expiredOrders = orderMapper.selectExpiredOrders(15); for (Order order : expiredOrders) { // 带条件更新：只有当前状态还是待支付(0)才置为已取消(5) int rows = orderMapper.updateStatusIfMatch(order.getId(), 5, 0); if (rows == 1) { for (OrderItem item : order.getItems()) { productMapper.restoreStock(item.getProductId(), item.getCount()); } } } } }

启动类上还要加 @EnableScheduling 这个注解，否则定时任务不生效，这个坑很多人踩过。cron 表达式从左到右是秒、分、时、日、月、周，0 */5 * * * ?表示每 5 分钟的 0 秒执行一次。演示验证时可以把 15 分钟改成 1 分钟，cron 改成*/10 * * * * ?，方便当场截图展示自动关单效果。

这里同样用 updateStatusIfMatch 带状态条件更新，避免和用户「恰好正在支付」的请求竞争：如果用户刚支付成功，状态已经是 1，条件更新匹配不上就不会被误取消。单机部署下定时任务没问题，如果是分布式部署，多台机器会重复执行同一个任务，需要引入分布式锁，毕设规模可以不展开。

3.5 把 Vue 前端打包进 SpringBoot：一个 jar 跑完整演示

毕设答辩最常见的部署方式，是把 Vue 前端构建产物放进 SpringBoot 的 static 目录，最终只交付一个可执行的 jar。这样做的好处很明显：评委不需要装 Node 环境，双击 jar 就能看到完整系统，前后端同源，跨域问题直接消失。

# 在 Vue 项目根目录执行 npm run build # 把构建产物复制到 SpringBoot 的静态资源目录 cp -r dist/* ../backend/src/main/resources/static/ # 重新打包 mvn clean package -DskipTests

复制完成后启动 SpringBoot，访问 http://localhost:8080/ 就是前端页面。需要注意 Vue Router 的 history 模式在刷新子路由时会 404，因为后端没有对应的路由映射，两个处理办法：一是把路由改成 hash 模式，URL 会多一个 # 号，省事；二是在后端加一个转发控制器，把所有非 /api 路径都 forward 到 /index.html，二选一即可。前端打包进 static 之后，SpringBoot 项目结构就变成「后端代码 + 前端页面」一体，这个方案在论文的「部署与测试」章节里很好写。

4. 毕设最容易翻车的 5 个坑：从跨域到超卖的排查记录

毕设系统 90% 的问题集中在几个固定点上：配置、并发、状态更新。下面这几条是我自己和身边同学真实踩过的坑，每一条按「现象 → 原因 → 解决」写，对照排查能省不少时间。

4.1 前端请求接口报 CORS，能看到请求但拿不到响应

现象：Vue 跑在 8081，SpringBoot 跑在 8080，浏览器控制台报 CORS error 或 Failed to fetch，Network 里请求状态是 pending 或直接失败。

原因：不同端口就是不同源，浏览器同源策略拦截了跨域响应。这个问题看起来像玄学，实际就是响应头里缺少 CORS 字段。

解决：后端加一个全局跨域配置：

@Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/api/**") .allowedOriginPatterns("*") .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS") .allowedHeaders("*") .allowCredentials(true); }

另一个思路更省事：前端开发时用 Vite 的 proxy 把 /api 代理到 8080，生产环境直接按 3.5 节把前端打进 jar，从源头避开跨域。这两种方式在论文「系统测试」里可以对比写，体现你考虑过部署形态。

4.2 并发下单时库存变成负数

现象：两个人同时下单同一个只剩 1 件库存的商品，两个订单都成功了，库存变 -1。

原因：代码里先查库存、判断是否充足、再执行更新，三步之间存在时间窗口，后一个请求读到了旧的库存值。

解决：按 3.3 的方式，扣库存用一条带条件的 UPDATE 完成。如果项目已经用了「先查后扣」的写法，临时补救可以给商品行加 SELECT ... FOR UPDATE 悲观锁，但并发会下降。论文里建议把两种方案都写出来，用实验数据证明乐观锁在单商品场景下足够用。

4.3 SpringBoot 版本太高，启动直接失败

现象：从官网生成的最新版项目，启动时报 ClassNotFoundException 或 BeanDefinitionStoreException，网上搜的解决方案全都对不上。

原因：SpringBoot 3.x 换了 jakarta 命名空间，老教程里 javax.servlet、老版 mybatis-spring-boot-starter 全都不兼容，JDK 版本不够也会连环报错。

解决：毕设直接锁定 Spring Boot 2.7.x + JDK 1.8 或 JDK 11 + mybatis-spring-boot-starter 2.3.x。版本选型写进论文「相关技术」章节时，注明选择稳定版本是基于生态兼容性考虑，答辩老师反而会认可这种工程判断。

4.4 插入中文变问号，时间差 8 小时

现象：订单地址、商品名称存进数据库变成 ???，create_time 比本地时间早 8 小时。

原因：JDBC 连接串没带编码和时区参数，MySQL 会话时区默认不是 Asia/Shanghai。

解决：连接串固定带上 useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai 三个参数；建库时指定 CHARSET=utf8mb4。utf8mb3 存不了生僻字和 emoji，现在统一用 utf8mb4 最省心。这两个参数在论文数据库设计章节里最好提一句，属于「非功能需求」的一部分。

4.5 订单状态被「跳过」或被「往回改」

现象：数据库里订单直接从待支付改成了已完成，或者用户重复提交取消请求，把已经送达的订单取消了。

原因：状态更新用了 updateById，整行无条件覆盖，状态机形同虚设。

解决：所有状态变更都走带条件的 SQL：

<update id="updateStatusIfMatch"> UPDATE orders SET status = #{targetStatus} WHERE id = #{orderId} AND status = #{expectedStatus} </update>

更新行数为 0 说明状态已被其他请求改变，此时按冲突处理而不是强制覆盖。比如用户刚刚完成了支付，状态从 0 变成 1，取消请求只能匹配 status=0，匹配不上就不会执行取消。这段代码对应的设计描述，在论文里就叫「基于状态机约束的订单安全更新」。

5. 把系统落成毕业论文：文档结构、ER 图与查重避坑

系统做完只是完成了一半。基于SpringBoot的校园外卖系统的毕业论文，常见问题不是没内容写，而是内容堆得没结构。论文不是代码粘贴板，是「设计决策的记录」。以下按写论文的顺序拆解。

5.1 论文结构怎么定：目录就是系统的设计说明书

论文目录建议严格按软件工程的顺序走，每章对应到代码里的一个模块，写的时候不会没话说。一个成熟可行的章节结构如下：

这个结构最有价值的地方是「第四章对应数据库与状态机、第五章对应 service 层代码、第六章对应压测数据」，每一章都能从后端代码里找到原材料。常见的失败写法是第二章相关技术写 8000 字博客搬运，第四章只有两张图，头重脚轻，导师一眼就能看出来。

5.2 图比字重要：三张图决定论文的下限

第一张是 ER 图，实体对应表，属性对应字段，关系对应外键逻辑：用户与订单 1:N、订单与订单明细 1:N、商家与商品 1:N。画图时注意用 crow's foot 标记，不要自己发明符号。第二张是用例图，四个角色各放一坨用例，学生用例必须完整覆盖浏览商品、加入购物车、下单、支付、取消订单、确认收货，管理员用例覆盖商家审核、订单统计、骑手管理。第三张是下单时序图，消息按时间从上到下：用户 → 后端 Controller → OrderService → ProductMapper 扣库存 → OrderMapper 写订单，标清楚每一步的返回。图里的命名要和代码、数据库完全一致，老师交叉比对发现对不上会扣印象分。

5.3 查重没有后悔药：代码、截图和公共配置怎么处理

血泪经验是：查重的核心机制是连续字符匹配，公共的 pom.xml、application.yml 这些配置很容易和网上现有论文重复。做法是把关键配置放正文讲解，完整 XML 放附录，减少正文命中。SpringBoot 自动装配、MyBatis 原理这些框架「套话」段落，一定要用自己的话重新组织，整段抄博客是查重重灾区。核心业务代码建议按自己的命名习惯重写一遍，变量名、注释、拆行都改一改，既降低重复率，也逼着自己真正读一遍代码。界面截图不参与查重但占版面，数据库表结构用「字段名/类型/说明」表格呈现，比大段代码更有工作量感。最后，学校指定的查重系统都支持引用标注，直接引用的公开资料按格式标注好，控制在合理比例内。

5.4 答辩前把这三个问题答顺

答辩老师基本不刁难人，问来问去就那几个点：SpringBoot 自动装配原理是什么；超时未支付订单怎么处理；数据库为什么这样设计、订单状态怎么控制。每个问题都按「设计思路 → 代码位置 → 怎么验证」三段来答。比如超时订单那题，先说设计思路是定时任务加状态机约束，再说 OrderTimeoutTask 里每 5 分钟扫一次、超 15 分钟未支付自动取消并回补库存，最后说怎么验证——把时间参数调成 1 分钟，下一轮任务日志里就能看到关单记录。能对着屏幕讲顺，基本就稳了。

6. 用压测给答辩加点硬数据：响应时间、超卖校验与定时关单

答辩时最有说服力的不是功能演示，而是数据。功能演示只能证明「能跑」，压测数据能证明「跑得动、没写错」。我一般用 JMeter 做一轮最简单的压力测试，全程不超过半小时，但论文第六章立刻有东西可写。

步骤很简单：JMeter 里新建线程组，50 个线程、循环 10 次、Ramp-Up 设 5 秒；添加 HTTP 请求先登录拿到 token，用 JSON 提取器把 token 取出来传给下单接口；下单接口的请求头带上 Authorization；最后跑一次聚合报告，记录平均响应时间、TP90 和错误率。下单接口压测结束后，去数据库查商品库存，确认没有负数，再对照日志看定时关单任务是否按 cron 时间触发。

三个数据填进表格，测试章就有血有肉了。一个小技巧：下单接口扣库存后把剩余库存打到日志里，压测结束后和数据库对比，对上就说明乐观锁生效，对不上就回去检查 4.2 的坑。我当年答辩前只演示了功能，被评委问「你这系统能扛多少人同时下单」时答不上来，后来补了这页压测数据，同一个系统答辩评价完全不一样。希望你从一开始就把验证这一步留出时间，别像我一样临时抱佛脚。希望帮到你。

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