Spring Boot校园外卖系统实战：业务拆解、订单链路与并发控制

最近不少学弟学妹来问 springboot校园外卖服务系统（11768）这个项目怎么做，说源码下载了、环境也跑起来了，但打开 IDEA 之后不知道先看哪里，答辩的时候老师一问业务逻辑就发慌。我太理解这种状态了：这类毕设项目本质上是一个完整的电商系统，但又带着校园场景的特殊约束，如果没有把业务边界和技术选型想清楚，很容易做成“四个 CRUD 页面拼在一起”的玩具。

这篇文章就把这个项目从头到尾拆一遍，从业务功能、技术栈选型、数据库设计，到下单链路实现、常见踩坑、项目包装升级，一次性说透。不管你手里拿到的源码是哪个版本，只要你理解了背后的设计逻辑，换一套代码也能自己写出来，这才是做毕设和练手项目真正该有的收获。

1. 拆解“校园外卖服务系统”的真实业务边界

1.1 校园外卖和普通外卖平台有什么不同

很多人一上来就照着美团外卖的架构去套，这是最典型的误区。校园外卖场景的核心约束和普通外卖平台有四点明显区别。

第一，配送范围极小。普通外卖的配送半径是 3 到 5 公里，校园外卖往往就是一座校区内部，甚至只有几个宿舍区。这意味着地址管理不用做得很重，但必须精确到宿舍楼栋，否则骑手找不到人。

第二，订单高峰极度集中。下课时间就是订单洪峰，中午 11 点到 12 点半、下午 17 点到 18 点半这两段，订单量可能是平峰时段的十倍。这对系统的并发能力提出了要求，哪怕是个毕设项目，也要在接口设计上预留缓存和队列的空间。

第三，支付方式受限。很多校园场景下学生更习惯用校园卡或者微信小程序支付，而不是网页端的支付宝扫码。所以在设计订单状态机时，支付回调、订单超时取消这些逻辑必须考虑进去，而不是简单做一两个字段。

第四，商家多数是校内食堂和周边餐馆自配送。不会像外卖平台那样有独立骑手团队，所以商家的接单、出餐、配送状态回写就成了业务闭环里的关键一环。

这些特征直接推导出系统的功能清单：用户端要有店铺浏览、菜品加购、下单支付、订单跟踪；商家端要有菜品管理、接单出餐、营业统计；管理端要有用户审核、商家审核、基础数据维护。理解了这个边界，你就知道哪些功能是核心必做，哪些功能可以砍掉。

1.2 三类角色与最小可用功能集合

毕设项目最忌讳贪大求全。给系统划三条角色线，每个角色只做必要功能，才能保证在有限时间里把核心链路跑通。

我建议你拿到项目后，先逐个功能点去对号入座。如果一个功能你找不到对应的页面和接口，不要急着怀疑自己，先看是不是这个源码版本做了删减。很多付费源码会把管理端做得特别简陋，但用户端和商家端一定是完整的，因为那是演示的核心。

1.3 编号“11768”背后的项目构成

“11768”这类编号，在毕业论文选题平台和项目交易平台上很常见，本质是一个特定版本的教育项目包。这类项目包通常包含四部分：后端 Spring Boot 源码、前端页面（可能是 Vue 工程，也可能是 Thymeleaf 模板）、SQL 初始化脚本、以及一份配套的设计文档或论文模板。

这里要提醒一句：不要直接把源码拿到答辩现场说“这是我自己写的”。老师随便问一个字段为什么这么设计、订单状态在哪里流转，就能判断你有没有真正理解项目。正确做法是把源码当成一个参考实现，自己把核心模块重写一遍，或者至少把整个调用链路的每个环节都能讲清楚。后面我讲的每一个设计点，都是答辩时最可能被追问的地方。

2. 技术选型：为什么这套组合是练手项目的“黄金配置”

2.1 Spring Boot 3.x 还是 2.x：第一道分水岭

打开项目先看 pom.xml 里的 Spring Boot 版本，这决定了你后面所有依赖的写法。

如果用的是 Spring Boot 3.x，要求 JDK 17 以上，而且很多坐标从 javax.* 变成了 jakarta.*。比如引入 Redis、MyBatis-Plus 的版本都要跟着升级，网上的老教程基本就对不上了。如果用的是 Spring Boot 2.7.x，JDK 8 就能跑，生态资料最齐全，百度一下能查到大量配置案例。

从就业和实用的角度看，我建议优先跑源码自带的版本，不要自己动手升级。Spring Boot 版本升级看着简单，改个号就行，实际上牵扯到一堆兼容问题。热搜词里有一条“springboot版本太高”，说的就是这种翻车现场：为了追新升级到 3.x，结果第三方 starter 集体报错。

一个能稳定运行的参考 pom 配置大概长这样：

xml复制<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>2.7.18</version>
    <relativePath/>
</parent>

<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
    </dependency>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-data-redis</artifactId>
    </dependency>
    <dependency>
        <groupId>com.baomidou</groupId>
        <artifactId>mybatis-plus-boot-starter</artifactId>
        <version>3.5.3.1</version>
    </dependency>
    <dependency>
        <groupId>mysql</groupId>
        <artifactId>mysql-connector-java</artifactId>
        <version>8.0.33</version>
    </dependency>
</dependencies>

这个组合的好处是：版本稳定、网上资料多、遇到问题基本都有现成答案。做毕设的首要目标是“跑得起来 + 讲得清楚”，而不是“版本最新”。

2.2 ORM 选 MyBatis-Plus 而不是纯 MyBatis 的原因

很多教学版 Spring Boot 项目用的是纯 MyBatis，XML 里堆一大片 SQL。但校园外卖这种业务，单表 CRUD 占了 70% 以上，纯手写 Mapper 太浪费。MyBatis-Plus 在 MyBatis 基础上封装了 BaseMapper，内置了增删改查方法，还带分页插件，特别适合这种以 CRUD 为主的管理系统。

比如商家添加菜品，传统写法要在 XML 里写 insert 语句，用 MyBatis-Plus 一行就够：

java复制public interface ProductMapper extends BaseMapper<Product> {
}

然后 Service 层直接调用：

java复制productMapper.insert(product);

菜品列表分页查询：

java复制Page<Product> page = new Page<>(current, size);
LambdaQueryWrapper<Product> wrapper = new LambdaQueryWrapper<>();
wrapper.eq(Product::getMerchantId, merchantId)
       .eq(Product::getStatus, 1)
       .orderByDesc(Product::getCreateTime);
return productMapper.selectPage(page, wrapper);

相比之下，纯 MyBatis 的优势是 SQL 可控，适合查询极其复杂的场景。但校园外卖系统的订单查询、菜品列表、用户管理都是标准查询，用 MyBatis-Plus 能把开发效率提高一倍。答辩时如果老师问为什么不用 JPA，你可以回答：JPA 的自动映射在复杂查询场景下调试成本高，MyBatis-Plus 既能保留 SQL 的灵活性，又有现成的单表 CRUD，更适合这个项目的实际需求。

2.3 Redis、JWT 和前端技术的定位

这套系统里 Redis 不是摆设。最典型的使用场景有三个：图片验证码存储、店铺/菜品缓存、登录 Token 管理。验证码存入 Redis 并设置 5 分钟过期，可以有效防止验证码暴力和重复使用；店铺列表和菜品列表这类高频读、低频写的数据，缓存到 Redis 后，接口响应能从几百毫秒降到十几毫秒。

登录鉴权建议用 JWT（JSON Web Token），无状态、适合前后端分离。用户登录成功后返回一个 token，前端存在本地，后续每次请求在请求头里带上。后端有一个拦截器校验 token 和用户角色，这样用户端、商家端、管理端共用一套校验逻辑，只是角色不同。

前端技术栈就看源码用了什么。如果源码是 springboot + vue 前后端分离，你至少要知道前端工程在哪个目录、接口地址在哪配置；如果是 Thymeleaf 方案，页面由后端渲染，就不存在跨域问题，但前后端分离的训练价值会少一些。从毕设角度说，Vue 前后端分离方案在答辩演示时更出效果，也更容易讲出东西。

2.4 一个可落地的分层架构

不管源码具体怎么拆，一个好的 Spring Boot 项目目录结构应该是这样：

code复制src/main/java/com.xxx.takeout
├── common          // 统一返回体、异常处理、常量类
├── config          // 配置类：Redis、拦截器、WebMvc
├── controller      // 接口层，只负责参数接收和返回
├── service         // 业务层，核心逻辑全部在这里
├── mapper          // 数据访问层，MyBatis-Plus 的 Mapper
├── entity          // 数据库实体类
├── dto             // 前端交互数据对象
└── vo              // 视图返回对象

Controller 层做三件事：接收参数、调用 Service、返回 Result。Service 层写业务规则，事务控制、状态判断、金额计算都在这里。Mapper 层只管数据读写。这种分层的价值不只是规范，更重要的是排查问题时能快速定位：接口报错了先在 Controller 层看参数，业务不对去 Service 层检查逻辑，数据不对就去 Mapper 层查 SQL。

统一返回体是整个项目的地基，推荐写成泛型类：

java复制@Data
public class Result<T> {
    private Integer code;
    private String message;
    private T data;

    public static <T> Result<T> success(T data) {
        Result<T> result = new Result<>();
        result.setCode(200);
        result.setMessage("操作成功");
        result.setData(data);
        return result;
    }

    public static <T> Result<T> error(String message) {
        Result<T> result = new Result<>();
        result.setCode(500);
        result.setMessage(message);
        return result;
    }
}

再加上一个全局异常处理器 @RestControllerAdvice，统一捕获业务异常和系统异常，前端拿到的错误信息就不会是乱七八糟的堆栈了。

3. 数据库设计是这类系统最容易翻车的地方

3.1 核心表的拆分与字段设计

校园外卖数据库表不需要太多，能覆盖核心链路就行。我见过做得比较合理的源码，一般维持在 9 张左右。别小看这个数量，每张表都是业务模型的映射，多一张冗余表、少一张关联表都会出问题。

订单主表和订单明细表必须分开设计，一个订单对应多条菜品明细，这在电商领域叫“订单头 + 订单行”模型。如果把菜品信息直接塞进订单表，后续做销量统计、商家结算都会很痛苦。

表之间的关联，我建议用逻辑外键而不是物理外键。逻辑外键就是普通字段，比如 order_item.product_id 指向 product.id，但不建 FOREIGN KEY 约束。理由是物理外键在删除和修改时约束太多，一旦数据初始化脚本顺序不对就会报错，而且基于逻辑外键做分页和统计性能更好。这个说法答辩时也能作为你的设计亮点。

3.2 订单金额存储：为什么不能用 Float

这个坑几乎每个做电商系统的人都要踩一次。数据库里的金额、Java 里的金额，统统不能用 float 和 double，要用 decimal 和 BigDecimal。

道理很简单：计算机用二进制表示小数，0.1 在二进制里是无限循环小数，浮点数运算会出现 0.1 + 0.2 = 0.30000000000000004 这种结果。课程设计功能少可能察觉不到，一旦算合计、算优惠、算退款，错误就会持续累积。

我见过某个版本的源码把订单总金额设计成 double，看起来能跑，但只要有两个菜品单价是 9.9 和 8.7，算出来的总金额就会变成 18.600000000000005，数据库里存下这种数值，后端给前端的 JSON 都能让人看懵。

正确做法是数据库字段用 decimal(10, 2)，Java 代码里用 BigDecimal，或者更稳妥的做法是以“分”为单位的整数存储。用 BigDecial 时注意 new BigDecimal("19.9") 和 new BigDecimal(19.9) 的区别，前者用字符串构造不会有精度问题，后者用 double 构造反而会引入精度损耗。

3.3 状态字段用 Int 还是 String、如何设计状态机

订单状态是整个系统最核心的状态机。推荐用 Integer 加常量类定义，而不是直接写字符串。用 Int 的好处是省空间、判断快，而且迁移到其他语言都通用。

我的建议是定义如下状态常量：

java复制public class OrderStatus {
    public static final int PENDING_PAYMENT = 0;   // 待支付
    public static final int PAID = 1;              // 已支付待接单
    public static final int ACCEPTED = 2;          // 商家已接单
    public static final int DELIVERING = 3;        // 配送中
    public static final int COMPLETED = 4;         // 已完成
    public static final int CANCELLED = 5;         // 已取消
    public static final int REFUNDING = 6;         // 退款中
}

状态流转规则：

• 待支付 → 已支付（用户支付成功回调触发）
• 待支付 → 已取消（超时未支付自动取消，或用户手动取消）
• 已支付 → 商家接单（商家端点击接单）
• 商家接单 → 配送中（商家出餐并点击开始配送）
• 配送中 → 已完成（用户确认收货或系统自动确认）
• 已支付 → 退款中 → 已取消（用户申请退款，商家同意后退款）

答辩时如果老师问“订单状态怎么保证不会乱跳”，你就要回答两步：第一是服务端每个状态变更都在 Service 层做前置校验，比如只有待支付订单才能取消；第二是状态更新语句要带上当前状态条件，比如 UPDATE orders SET status = 2 WHERE id = ? AND status = 1，防止并发情况下状态被覆盖。

3.4 索引与关联查询优化

毕设项目数据量不大，但建索引这个习惯得有。订单表一定会在列表页按用户查、按商家查、按状态筛选，所以要给 user_id、merchant_id、status、create_time 建索引。菜品表要给 merchant_id 和 status 建索引，购物车表给 user_id 建索引。

列表查询一定不要用 select * from orders where user_id = ? 这种不带分页的查询，数据量一多页面直接卡死。用 MyBatis-Plus 的分页插件，加上 order by create_time desc，每次只拿一页数据。管理端统计订单总量用聚合查询，别循环查数据库，这些都是最基本的性能意识。

4. 从“用户下单”到“订单完成”的完整链路实现

4.1 下单接口的设计：一次请求还是多次请求

很多教学项目把创建订单分成了“提交订单”“确认支付”“支付成功”三个接口。前端调一次就往 orders 表插一条记录，用户没支付就丢在那里，体验很糟糕。

正确做法应该是：创建订单一次完成，订单号、金额、明细、状态初始值全部在一个事务里生成，用户拿到订单号后再去支付。核心 Service 方法大致是：

java复制@Transactional(rollbackFor = Exception.class)
public OrderVO createOrder(CreateOrderDTO dto) {
    // 1. 校验参数：用户地址、商品信息、商家是否营业
    // 2. 计算总金额：遍历购物车商品，用 BigDecimal 累加
    // 3. 生成订单号：日期 + 随机数，如 202501011200001234
    // 4. 插入订单主表，状态置为 PENDING_PAYMENT
    // 5. 插入订单明细表，记录商品快照信息（名称、单价）
    // 6. 扣减菜品库存
    // 7. 清空购物车中已下单的商品
    return OrderVO.from(order);
}

注意订单明细里存的是商品快照，也就是下单那一刻的商品名称和单价。这样即使商家后续改了菜价，历史订单的金额和明细也不会变。这是电商系统的标准做法，答辩时讲到这一点很加分。

4.2 库存扣减与并发控制

库存扣减是并发问题最典型的场景。两个用户同时下单同一道菜，如果代码是这样写的：

java复制Product product = productMapper.selectById(productId);
if (product.getStock() < quantity) {
    throw new BusinessException("库存不足");
}
product.setStock(product.getStock() - quantity);
productMapper.updateById(product);

那么在高并发下，两个请求同时读到库存是 1 份，都判断库存足够，然后都执行扣减，库存就变成了负数。这就是经典的“超卖”问题。

最简单的解决方式是使用乐观锁，在数据库层面用条件更新来保证原子性：

sql复制UPDATE product SET stock = stock - #{quantity}
WHERE id = #{productId} AND stock >= #{quantity}

stock >= #{quantity} 这个条件很关键，如果库存不足，受影响行数为 0，据此抛出库存不足异常。这种方式不需要加分布式锁，性能也好，毕设项目完全够用。

4.3 订单状态流转与超时处理

超时未支付订单怎么处理？最简单可靠的方案是定时任务扫表。Spring 自带的 @Scheduled 注解就能实现：

java复制@Component
public class OrderTimeoutTask {

    @Scheduled(fixedRate = 60000)
    public void cancelTimeoutOrders() {
        // 查询创建时间超过 15 分钟且状态为 PENDING_PAYMENT 的订单
        List<Orders> orders = orderMapper.selectTimeoutOrders(15);
        for (Orders order : orders) {
            // 先将状态从待支付改为已取消，通过 status 条件避免重复处理
            int rows = orderMapper.cancelOrderById(order.getId(), OrderStatus.PENDING_PAYMENT);
            if (rows > 0) {
                // 恢复菜品库存
                restoreStock(order.getId());
            }
        }
    }
}

MySQL 的 create_time 字段可以直接在查询里做时间比较：WHERE status = 0 AND create_time < DATE_SUB(NOW(), INTERVAL 15 MINUTE)。这里把状态条件也放进 SQL，能防止多个定时任务实例之间的重复取消。

如果项目想做得更“高级”，可以引入 RabbitMQ 或 ActiveMQ 的延迟队列。下单时发一条延迟 15 分钟的消息，消费者收到消息后检查订单状态，如果是待支付就取消。这个方案的好处是不用每分钟扫一遍数据库，但引入了新的中间件，对毕设来说可选，但要做就得把 MQ 跑通并讲明白。

4.4 商家侧接单与配送状态回写

商家端接单是状态机的关键操作。商家登录后，看到待接单列表，点击接单，后端接口先校验订单状态确实是已支付，才允许状态改为已接单：

java复制public void acceptOrder(Long orderId, Long merchantId) {
    Orders order = orderMapper.selectById(orderId);
    if (!merchantId.equals(order.getMerchantId())) {
        throw new BusinessException("无权操作该订单");
    }
    if (order.getStatus() != OrderStatus.PAID) {
        throw new BusinessException("订单状态异常，无法接单");
    }
    order.setStatus(OrderStatus.ACCEPTED);
    orderMapper.updateById(order);
}

商家出餐后点击“开始配送”，状态变为配送中；骑手送达后用户可以确认收货，也可以由系统在超时后自动确认。

新订单的实时通知是一个体验点。最简单的方案是商家端前端每隔几秒轮询一次待接单数量，虽然不高大上但稳定可跑。想做得更即时，可以在 Spring Boot 里集成 WebSocket，新订单落库时向商家频道推送一条消息。WebSocket 在毕设里属于亮点功能，建议有余力的同学尝试。

5. 常见踩坑记录：从登录态到支付回调

5.1 登录鉴权：Token 有效期和刷新策略

第一个坑是 Token 有效期设置。有效期太短，比如 30 分钟，用户用着用着就提示登录过期；有效期太长，比如 7 天，安全风险又高。

我建议的折中方案是：Token 有效期 2 小时，后端提供一个 refreshToken 接口，前端在拦截器里检测到 token 快过期时自动调用刷新。毕设项目做到这一步已经很能说明问题了。

另外一个很容易踩的坑是 Token 只存 userId 不管角色。用户端和商家端用的是同一套用户表，登录后必须在 token 里带上角色标识，拦截器才能区分请求来源。否则可能出现用户端能调用商家接单接口这种权限漏洞。

5.2 跨域配置与拦截器放行

前后端分离项目里，后端跑在 8080，前端跑在 8081，浏览器直接请求就会被 CORS 拦截。Spring Boot 解决跨域很简单：

java复制@Configuration
public class CorsConfig implements WebMvcConfigurer {

    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/**")
                .allowedOrigins("http://localhost:8081")
                .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS")
                .allowedHeaders("*")
                .allowCredentials(true)
                .maxAge(3600);
    }
}

最容易翻车的是带 Token 的拦截器把预检请求 OPTIONS 也拦了。浏览器在发起跨域 POST 请求前会先发一个 OPTIONS 请求，如果你的拦截器没有放行 OPTIONS 和路径 /login，前端就会一直报跨域错误或者 401。正确做法是在拦截器的 preHandle 方法里判断请求方法，如果是 OPTIONS 直接返回 true。

5.3 金额精度丢了一分钱

前面讲了金额要用 BigDecimal，这是原理层面。实操层面还有一个高频坑：前端 JavaScript 的 Number 类型在处理超大整数或小数时也会丢精度。比如前端计算购物车合计，两件商品单价分别是 9.9 和 19.9，JavaScript 算出来可能是 29.799999999999997，这时候如果直接把前端算好的金额传给后端存入数据库，一分钱的差异就产生了。

务实的做法是：前端只负责展示，金额计算以服务端为准。前端把商品 ID 列表和数量传给后端，后端从数据库读取单价，重新计算总金额。这个设计在答辩时也是一句响当当的回答：“我们的金额计算全部在服务端完成，前端只做展示，保证数据安全性和一致性。”

5.4 Redis 缓存穿透与缓存不一致

用 Redis 缓存店铺列表、菜品列表时，最常见的坑是缓存穿透和缓存与数据库不一致。

缓存穿透意思是查一个数据库里根本不存在的笛卡尔 id，每次请求都直接打到数据库，Redis 完全起不到保护作用。解决方案是“空值缓存”：查询结果为空时，也往 Redis 里放一个空对象，设置 2 到 5 分钟过期。

缓存不一致的根源是更新了数据库没有及时删除缓存。最实用的方案是 Cache Aside Pattern：查询时先读缓存，没有则读数据库再回填；更新时先改数据库，再删除缓存。下次查询时缓存缺失，自动回填最新值。这个方案简单可靠，不用引入消息队列，适合绝大多数业务。

5.5 文件上传：图片偶尔 404

菜品图片上传，很多毕设项目直接把文件存到服务器本地磁盘，上传时返回一个 http://localhost:8080/img/xxx.jpg 这样的地址。坑就在这：图片能上传成功，但页面一刷新就 404。

原因通常是 Spring Boot 没有映射静态资源目录。需要在配置类里加资源映射：

java复制@Override
public void addResourceHandlers(ResourceHandlerRegistry registry) {
    registry.addResourceHandler("/img/**")
            .addResourceLocations("file:" + uploadDir + "/");
}

uploadDir 是服务器上的绝对路径，比如 D:/upload/ 或 /home/app/upload/。这个坑特别隐蔽，因为开发环境直接访问工程目录下的资源偶尔能通，但部署到服务器或者换了运行目录就失效。

如果想让项目显得更有工程感，可以把 MinIO 集成进来做对象存储。MinIO 是开源的，接口兼容亚马逊 S3，支持 Docker 一键部署。菜品图片上传后返回一个带签名的预签名 URL，图片访问不依赖后端进程，部署在云服务器上也不怕丢图片。这个点写进简历是实打实的亮点。

6. 如何把这个项目从“能跑”做到“值得写进简历”

6.1 从单体到可扩展：引入消息队列和定时任务

如果只是照着源码跑一遍，这个项目的含金量撑不起一场毕业答辩。想让它变得有价值，核心是把别人没有的点补上。

校园外卖系统最值得扩展的就是异步化。下单成功后要通知商家、用户下单成功后要发确认消息、订单超时要取消，这些任务如果用同步调用来做，一个接口做完要几百毫秒，体验很差。引入 ActiveMQ 或 RabbitMQ 之后，下单接口只需要把消息发到队列就立刻返回，消费者异步处理后续任务。

加入 MQ 之后，你的技术栈就从“Spring Boot 全家桶”升级为“Spring Boot + 消息中间件”，这在简历上的分量完全不一样。面试官问起来你也有内容可讲：为什么用 MQ、消息怎么保证不丢失、消费失败怎么重试。当然，只要学了 MQ，你得真能把项目里的场景说清楚，不能为了写简历而硬塞一个自己都讲不透的知识点。

6.2 数据统计与分析

校园外卖系统的数据统计不做就太可惜了。用户端有消费记录，商家端有订单流水，管理端有全局数据，这些数据天然适合做可视化。

最简单的方式是给商家端加一个营业统计页面：今日订单数、今日营业额、热门菜品 Top 5、近七天订单趋势。接口层面用一条聚合 SQL 就能算出来：

sql复制SELECT DATE(create_time) AS order_date, COUNT(*) AS order_count, SUM(total_amount) AS total_amount
FROM orders
WHERE merchant_id = #{merchantId}
  AND create_time >= DATE_SUB(CURDATE(), INTERVAL 7 DAY)
GROUP BY DATE(create_time)
ORDER BY order_date

前端可以用 ECharts 画柱状图和折线图，接口返回什么字段，前端就渲染什么图表。这个功能开发成本低，但非常出效果，答辩演示时把页面切到统计图，视觉冲击力远大于干巴巴的列表。

6.3 测试与部署

很多毕设项目只有开发环境，没有测试和部署环节，这其实是减分项。最起码要做到两件事：

接口测试用 Postman 或 Apifox，把登录、下单、接单、取消订单这些核心流程的接口调通，截图保存到测试文档里。这个工作不写代码但很重要，因为论文的“系统测试”章节必须有截图支撑。

部署用 Docker，给项目写一个简单的 Dockerfile：

dockerfile复制FROM openjdk:8-jdk-alpine
COPY target/takeout.jar /app.jar
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "/app.jar"]

再加一个 docker-compose.yml 把 MySQL、Redis、Spring Boot 三个容器串联起来。这套部署方案写进论文或简历，比“本地 IDEA 运行”要专业一个档次。

6.4 毕业论文写作与答辩注意事项

论文框架不用我说太多，每个学校都有模板。但有几个点必须提醒：

第一，需求分析不要抄模板，要把校园外卖场景的特殊性写清楚，比如高峰订单集中、按宿舍楼栋配送、商家自配送等。这些内容直接来源于你对业务边界的理解，而不是泛泛的“系统满足用户需求”。

第二，数据库设计章节一定要包含实体关系图和核心表结构说明，重点写清订单主表与订单明细表为什么拆开，金额字段为什么用 decimal。能解释清楚设计原因，论文深度立刻不一样。

第三，流程图要画清楚自己实现的那条链路。常见的是用户下单时序图、订单状态流转图、商家接单流程图。答辩时老师很喜欢看着流程图问问题，所以图怎么画的，你就要能怎么讲。

答辩现场还有一个高频问题：“你这个项目和美团外卖有什么本质区别？”如果你把校园配送范围、订单高峰、商家自配送这些点讲出来，老师立刻就能判断你是真做过分析的。如果你只回答“功能差不多”，那基本就坐实了是下载的代码。

说回这个 springboot校园外卖服务系统（11768），它最值钱的不是那几份源码和文档，而是逼迫你去思考一个真实业务系统的完整链路：从角色划分、数据库建模，到状态机设计、并发控制、缓存一致性。我做项目的一贯建议是：先别急着写代码，花一个晚上把订单状态流转图和数据表关系图画出来，画明白了，后面写代码就跟照着地图走一样，每一步都知道自己在干什么。如果你手里已经有了源码，那更要先做这一步，用图去还原别人的设计意图，再动手去改、去补、去重构，这样到了答辩台上，你才能像一个真正做过系统的人那样，从从容容地回答问题。