SpringBoot医疗保健品销售系统：从数据库设计到答辩要点全解析

毕业设计选 Java + SpringBoot 做医疗保健品销售系统，算是 Web 开发方向里非常典型的一类选题了。这类项目表面上是个电商系统，但真正落地的时候会牵扯出用户认证、商品管理、订单状态机、库存并发、支付回调、后台权限控制一大堆问题，尤其是“医疗保健品”这个定语，让它在商品信息展示和分类逻辑上和普通卖衣服鞋子的商城有明显的差异。这篇文章我会完整拆解这个选题的设计思路、核心模块划分、数据库建模、后端实现要点，以及答辩时最容易被人追问的技术细节，全部基于 SpringBoot + MyBatis Plus + Vue 这套最常用的技术栈展开，聊点实操层面的东西。

如果你正在做类似的毕设，或者想把这个方向包装成求职项目写进简历里，这篇文章应该能帮你少走不少弯路。我会把从需求分析到功能落地中间那些“文档里不会明说、但做的时候一定会遇到”的细节都摊开讲清楚。

1. 项目定位与核心需求拆解

1.1 这个系统到底是做什么的

先把这个项目一句话说清楚：它是一个面向保健品消费者和平台运营方的在线交易系统，用户可以在平台上浏览养生产品、查看成分说明和适用人群、加入购物车并下单购买；后台管理员则可以管理商品上下架、处理订单、配置分类和轮播图。

从毕设的角度看，这个题目的好处在于——它天然具备“电商系统”的完整性。只要把商品、用户、订单、购物车、支付这几条核心链路打通，再加上后台管理的权限控制，整个项目的技术含量和代码量就已经足够撑起一篇合格的毕业设计了。而且和普通商城相比，保健品类目多了“适用人群”“功效标签”“禁忌提醒”这一类字段，这些细节恰恰是体现你对业务理解深度的点，答辩的时候老师很喜欢往这个方向问。

从求职的角度看，这类项目也很适合拿来包装，因为它涵盖了 SpringBoot 后端常见的所有基本功：RESTful API 设计、JWT 登录鉴权、Spring Security 权限模型、数据库事务处理、文件上传下载、以及简单的并发控制。这些技能点放在简历上是完全拿得出手的。

1.2 核心业务模块划分

整个系统按角色可以拆成两个端，用户端和后台管理端，我这里按后端模块的维度帮你拆一遍，这样你建项目结构的时候心里有数。

第一块是用户模块。包含注册、登录、个人信息维护、收货地址管理。保健品平台有一个特点——很多用户是给家里老人买的，所以收货地址管理里最好加上“收货人姓名”和“手机号”的完善校验，不能只存一个简单的字符串地址了事。

第二块是商品模块。包含商品分类、商品 SPU/SKU 管理、商品详情、搜索与筛选。保健品商品的字段比较多，除了基础的价格库存，还要有“适用人群”“主要成分”“保健功能”“禁忌人群”“生产厂家”“批准文号”这些信息。这些字段在产品经理眼里是合规要求，在技术实现上就是一张商品表的字段设计，含金量就在这个建模过程里体现。

第三块是购物车模块。包含加购、修改数量、删除、勾选结算。购物车实现方案有两种，一种是纯前端 localStorage，一种是后端持久化，我建议做后端版本。理由很简单——后端版本文档里更好写，答辩时也能顺带讲一讲“为什么用 Redis 存购物车更合适”这种加分问题。

第四块是订单模块。包含下单、订单列表、订单详情、取消订单、确认收货。这一块是整个系统的核心难点，也是事务和状态机最容易出问题的地方。

第五块是后台管理模块。包含管理员登录、商品管理、订单处理、用户管理、数据统计看板。

1.3 技术选型的几点考虑

技术栈这里我直接说结论：SpringBoot 2.7.x + MyBatis Plus + MySQL 8.0 + Redis + Vue 2/3 + Element UI，这套组合是现阶段毕设项目最稳的选择，没有之一。

关于版本我特意单独拎出来说，因为很多人在第一步就被卡住了。SpringBoot 3.x 要求 JDK 17 以上，但很多学校的毕设环境和教材还停留在 JDK 8，如果你不想在环境配置上浪费时间，就直接用 SpringBoot 2.7.x 搭配 JDK 8。这一个选择能帮你避开后面大量“版本不兼容”的坑。

数据库方面用 MySQL 8.0 或 5.7 都可以，建议 8.0，因为 8.0 的窗口函数、CTE 语法在后面做数据统计报表的时候会方便很多。Redis 用来做验证码存储和购物车缓存，可以做也可以不做，但做了之后整个项目的“技术深度”会明显上一个档次。

前端如果不是很擅长的话，不用把精力花在花哨的页面上，Vue 2 + Element UI 的表格表单组件就能覆盖后台管理端 90% 的需求，用户端再套一个现成的商城模板就够用了。真正决定你项目高度的是后端逻辑，不是页面好不好看。

2. 数据库设计与业务模型

2.1 核心表结构设计

数据库设计是一个 SpringBoot 项目最重要的地基。很多同学在建表的时候图省事，字段能省则省，结果做到订单模块的时候发现缺少关键字段，只能回去改表结构，又牵连到 VO、Entity、Mapper 层层改动，非常痛苦。

我按核心业务模块给你列一下最少需要哪些表：

用户端这边，user 表存放用户基本信息，包括 username、password、phone、avatar、status 几个核心字段。address 表存放收货地址，关联 user_id，字段包括收货人、手机号、省市区、详细地址，还可以加一个 is_default 标记默认地址。

商品这边，category 表分类，product 表存商品基本信息，product_detail 表可以存富文本详情，product_sku 表存具体的规格库存。保健品的 product 表字段建议这样设计：

这十二个字段看起来多，但每一列都有它存在的意义。尤其 approval_number 批准文号和 taboos 禁忌人群这两个字段，是保健品和普通商品拉开差异的地方。你如果在商品编辑页面给管理员留了这两个输入框，答辩时就可以解释：“保健品属于特殊食品，国家要求展示批准文号和禁忌信息，所以我在商品建模时特意增加了这些字段。”一句话就能让老师感受到你不是在盲目照搬电商模板。

订单这边，核心是 order 主表和 order_item 子表。order 表存订单编号、用户ID、总金额、订单状态、收货信息快照、支付时间等；order_item 表存该订单下的商品快照、单价、数量、小计。注意一定要做“快照”，因为商品的价格和名称之后可能修改，但用户下单那一刻的信息必须原样保留，这是电商系统的基本常识，也是答辩重点。

2.2 订单与库存的关系处理

订单和库存的关系，是整个系统里最需要动脑子的地方，也是最容易被问倒的地方。

先说最简单的方案：用户下单时直接扣减库存，用 UPDATE product SET stock = stock - #{count} WHERE id = #{id} AND stock >= #{count} 这样的 SQL 来做原子扣减。这条 SQL 能保证在高并发情况下不会出现超卖，因为数据库行锁会串行化同一商品的扣减操作。

但光扣库存还不够，还需要考虑订单状态。一个用户下单后如果一直不支付，库存就被白白占着。所以要做超时关单机制——用户下单后 15 分钟或 30 分钟内未支付，系统自动取消订单并把库存加回来。实现方式有三种：

一是定时任务扫描，用 Spring 的 @Scheduled 注解每分钟扫一次订单表，把超时未支付的订单改成已取消。二是延迟队列，用 RabbitMQ 的延迟消息实现，精度高但引入中间件，配置量大。三是 Redis 过期键监听，下单时设置一个带过期时间的 key，过期后回调关单。对于毕设项目，第一种最稳妥，代码量小、逻辑直观、答辩时也好讲清。

2.3 状态机设计

订单状态是电商系统里最经典的状态机模型。不要用简单的字典字段草草了事，我建议把状态定义成一个枚举类，从待支付到已完成定义清楚每个状态的流转方向。

常规的设计是这样的：

• 待支付（已下单未付款）
• 已支付（已付款待发货）
• 已发货（商家已发货）
• 已完成（用户确认收货或系统自动确认）
• 已取消（用户主动取消或超时取消）
• 售后中（针对保健品可能出现的退款退货需求）

每个状态允许的流转方向要明确。比如已支付只能流转到已发货，不能随意跳回待支付；已发货只能流转到已完成或售后。实现上，最简单的方式是在更新订单状态时加一个条件判断：UPDATE order SET status = #{newStatus} WHERE id = #{id} AND status = #{expectedStatus}，通过数据库的行级锁来保证并发环境下状态不会乱。

这里我要强调一个业务细节：保健品因为食品属性的特殊性，很多平台支持“收货后 15 天无理由退货”，这在订单状态里就会有“售后中”这个分支。哪怕你毕设项目不用做完整的售后流程，也建议在状态枚举里预留这个状态位，并在数据库设计文档里提一句，体现你对业务边界的考虑。

3. 后端核心实现与要点

3.1 项目骨架搭建与版本选择

前面说过建议用 SpringBoot 2.7.x，这里再补充几个关键依赖的版本搭配。

用 Spring Initializr 生成项目时，Group 填 com.example 这类域名倒写格式，Artifact 填项目名。Java 版本选 8，SpringBoot 版本选 2.7.18。依赖勾选 Spring Web、MyBatis Framework（如果你的初始化器支持）、MySQL Driver、Validation、Lombok，Redis 有需要也可以勾上。

这里有一个容易踩坑的地方：SpringBoot 2.7.x 自带的 spring-boot-starter-validation 从 2.3 之后不再默认引入 validation-api 了，所以参数校验的依赖要手动加。另外一个更常见的坑是 Lombok 版本和 JDK 版本的兼容性问题，如果你用的是 JDK 17 但 SpringBoot 是 2.7.x，需要把 Lombok 版本升级到 1.18.28 以上，否则会在编译时直接报错。

项目结构上，我强烈建议按功能分包而不是按技术分层分包。用 controller / service / mapper / entity 这种包结构，虽然直观，但代码一旦多起来就会乱成一锅粥。更合理的做法是按业务模块分包，类似 com.example.healthshop.modules.user、modules.product、modules.order，每个模块下再分 controller、service、mapper、entity。这样找代码快，后期扩展也方便。

3.2 登录鉴权与权限控制

登录鉴权这块，SpringBoot 生态里选择其实很多，传统做法是 Session + Cookie，现在的主流做法是 JWT。对于前后端分离的项目，JWT 几乎是标配，也是面试必问。

具体实现思路是这样的：用户输入账号密码登录成功后，后端用私钥生成一个 token，token 里可以包含用户ID、用户名、角色等非敏感信息，然后返回给前端。前端把 token 存到 localStorage 里，后续每次请求都在 header 里带上 Authorization: Bearer <token>。后端用一个拦截器 or Spring Security 的过滤器来解析 token，解析成功就把用户信息放入 ThreadLocal 或请求上下文，后面的业务代码就能直接拿到当前登录用户了。

JWT 的优点是无状态，服务器不需要存 session，水平扩展的时候不用考虑 session 同步。缺点也很明显，token 一旦签发无法主动失效，所以如果你做了“修改密码后强制下线”的功能，就需要配合 token 黑名单机制。

我用 Spring Security + JWT 给一个比较精简但是完整的方案，核心配置大概是这样的：

java复制@Configuration
@EnableWebSecurity
public class SecurityConfig extends WebSecurityConfigurerAdapter {
    
    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http.csrf().disable()
            .sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS)
            .and()
            .authorizeRequests()
            .antMatchers("/api/user/login", "/api/user/register").permitAll()
            .antMatchers("/api/admin/**").hasRole("ADMIN")
            .antMatchers("/api/product/**", "/api/cart/**", "/api/order/**").authenticated()
            .anyRequest().permitAll()
            .and()
            .addFilterBefore(jwtAuthenticationFilter, UsernamePasswordAuthenticationFilter.class);
    }
}

这里我用了 WebSecurityConfigurerAdapter 这个类，注意它在 Spring Security 5.7 之后被标记为废弃，5.8 开始移除，所以如果你用了 SpringBoot 2.7.x 配套的 Spring Security 5.7.x，还是可以用的，但要注意别换成 SecurityFilterChain 的新写法。如果你不小心用了 SpringBoot 3.x，就必须用新写法了，这也是为什么前面反复强调版本的重要性。

后台管理员和普通用户建议放在同一张 user 表，用 role 字段区分，role=1 是管理员，role=0 是普通用户。这样登录逻辑共用一套，权限判断时根据角色做不同的接口访问控制。安保方面，密码存储不要用明文，用 BCrypt 加密。Spring Security 自带 BCryptPasswordEncoder，直接注入使用即可。

3.3 下单流程与库存扣减的坑

下单是整个系统里最容易出 bug 的环节，没有之一。我先把常规的下单流程写出来，然后告诉你每一步有哪些隐藏的坑。

第一步是参数校验。前端传过来的商品ID、数量、收货地址ID这些参数，后端不能直接信，必须做二次校验。比如商品是否存在、是否上架、数量是否大于0、收货地址是否是当前用户的。这里用 @Validated 注解做 bean validation 就能覆盖大部分场景，但商品状态和归属类校验还是得在 service 层手写。

第二步是价格计算。正确的做法是后端从数据库查出当前商品的售价，乘上数量得到小计，所有商品的小计之和才是订单总金额。绝对不能信任前端传过来的总价字段，否则用户用浏览器开发者工具改一下价格参数，就能用一分钱下单，这也是电商系统最基础的安全底线。

第三步是库存扣减。扣减操作一定要发生在事务内，并且要尽早执行。一个典型的错误写法是先查库存，在 Java 里判断库存够不够，再执行 UPDATE 扣库存。这种方式在单线程下没问题，但并发一上来就会出问题：两个请求同时查库存都发现是 1 件，都通过判断，都执行扣减，库存就变成 -1 了。正确写法是使用条件更新的原子操作：

java复制@Transactional(rollbackFor = Exception.class)
public void createOrder(OrderCreateDTO dto) {
    // 1. 校验商品
    // 2. 计算金额
    // 3. 原子扣减库存
    int updated = productMapper.deductStock(skuId, count);
    if (updated == 0) {
        throw new BusinessException("库存不足");
    }
    // 4. 创建订单
    // 5. 创建订单项
    // 6. 清空购物车对应商品
}

对应的 SQL 是：

sql复制UPDATE product_sku SET stock = stock - #{count} 
WHERE id = #{skuId} AND stock >= #{count}

stock >= #{count} 这个条件就是防超卖的锁，如果库存不够，受影响行数为 0，业务层就能感知到并抛异常。执行这个扣减的 UPDATE 会获取该行数据的排他锁，所以同一时刻多个并发请求会在这里排队。

第四步是订单落库。订单编号建议自己生成，不要用数据库自增主键当订单号。常见做法是用时间戳 + 随机数或雪花算法生成一个唯一订单号，业务上方便查询，对外展示看起来也专业。

整个下单过程必须加上 @Transactional，保证扣库存、生成订单、清购物车这三个操作要么全部成功，要么全部回滚。

3.4 支付模块怎么处理

支付这块是毕设项目比较头疼的地方，因为真正的微信支付/支付宝支付需要企业资质和商户号，个人很难申请下来。但完全不做支付，整个购物流程又显得不完整。

我的建议是做一个“模拟支付”的模块。用户下单后跳到一个支付确认页，点击“模拟支付”按钮，后端直接把订单状态从待支付改成已支付，记录支付时间和支付流水号，再在备注里标注“模拟支付”。这样做有几个好处：第一，订单状态机能完整跑通，不影响后续的库存、发货、售后流程；第二，你把真实的微信支付接口调用流程写在设计文档里，说明沙箱环境和正式环境的差异，答辩不会有人认为你偷工减料；第三，如果导师一定要求集成真实支付，你再替换成对应的 SDK 即可，架构上不用改动。

支付成功后的回调处理是一个关键点。真实场景中支付回调是由支付平台服务器发起的，所以不能依赖前端跳转来修改订单状态，必须提供一个服务端接口接收回调通知。在模拟实现中，你可以在模拟支付成功时直接调用这个回调接口，把流程走通，以后接真实支付时把回调地址改成微信/支付宝的配置就行。

3.5 后台管理系统的核心功能

后台管理端其实占了这个项目很大一部分工作量，主要包括管理员登录、商品管理、订单管理、用户管理和数据统计。

商品管理是最重的一块。管理员需要能对商品做增删改查、上下架、设置分类、上传图片、编辑详情。图片上传建议在本地服务器存一份，同时在数据库里保存图片的可访问 URL。上传文件需要注意对文件类型做白名单校验，只允许 jpg、png、webp 等图片格式，文件大小也做限制，防止有人上传恶意文件。

订单管理这边，管理员需要看到所有用户的订单列表，支持按订单编号、用户、状态筛选，可以对订单执行发货操作。发货操作会修改订单状态并记录发货时间、物流单号。

数据统计看板可以用来辅助完成毕设的“系统测试”章节。用 ECharts 画几个图表，展示近 7 天订单量走势、近 30 天销售额 TOP10 商品、各分类占比等。SQL 方面就是 GROUP BY 按日期统计，加上 SUM 聚合，再和 LEFT JOIN 商品表关联，难度不高但页面效果很好。

4. 常见问题与排查技巧实录

4.1 SpringBoot 版本与 JDK 版本兼容问题

这一节说的都是实际跑项目时踩过的坑。SpringBoot 版本问题可以说是我见过毕设项目里出现频率最高的报错来源。

SpringBoot 2.x 系列不支持 JDK 17 以上的编译目标。如果你用的是 JDK 17，但项目里 SpringBoot 版本还是 2.x，编译的时候大概率会看到这样的错误：java: 警告: 源发行版 17 需要目标发行版 17。这通常不是代码问题，而是 IDE 的 Java 版本和项目编译器版本不一致。

解决方法是检查三个地方：Project Structure 里的 Project SDK 和 Project language level、Settings 里的 Java Compiler 的 target bytecode version、以及 Maven 的 pom.xml 里 java.version 属性。三者必须保持一致。如果你用的是 JDK 8，那 language level 和目标字节码版本都应该设成 8。

还有一个很隐蔽的坑是 Lombok 和 JDK 版本不兼容。当你看到一个报错说 You aren't using a compiler supported by Lombok, so Lombok will not work，这就是 Lombok 版本太老，不识别当前 JDK 版本，把它升级到 1.18.30 基本能解决。

4.2 事务不生效的几种情况

Spring 的 @Transactional 事务失效可以说是一个经典问题了，也是面试里常考的点。毕设项目里最容易踩的事务坑有以下几类。

第一类是没有走代理。Spring 的事务是基于 AOP 代理实现的，如果事务方法被同类内部调用，比如 OrderService 里的方法A调用同一个类里的方法B，方法B 上的 @Transactional 不会生效，因为这次调用没有经过代理对象。解决办法是把方法拆到不同的 Service 类，或者注入自己的代理。类A的methodA()调用类A的methodB()——这就是最典型的失效场景。

第二类是异常被吞了。@Transactional 默认只在 RuntimeException 和 Error 时才回滚，如果你在 catch 里把异常吃掉或者抛出了一个自定义的 checked Exception，事务依然会提交。解决办法是在 rollbackFor 属性里指定需要回滚的异常类，或者让自定义异常继承 RuntimeException。

第三类是数据库表不支持事务。用 MyISAM 引擎的表是不支持事务的，如果是 SSM 老项目或者手动建表，要注意表引擎必须是 InnoDB。另外如果你是用了 MySQL，默认引擎是 InnoDB 没问题，但如果从别的库导过来的表就难说了。

4.3 循环依赖的坑

循环依赖在 SpringBoot 2.6 之后默认不允许了，这是一个比较容易遇到的坑。具体场景是：ServiceA 里注入了 ServiceB，而 ServiceB 里又注入了 ServiceA，Spring 启动的时候会直接抛出循环依赖的异常。

怎么解决？最推荐的方式是重构代码，打破循环依赖。比如用户在 ServiceA 中需要用到 ServiceB 的逻辑，可以考虑把共用的逻辑抽到第三个 Service 或者工具类中。实在没法重构的情况下，可以用 @Lazy 注解延迟注入，比如在 ServiceA 的 ServiceB 字段上加 @Lazy，让 Spring 在第一次使用时再去创建 ServiceB 的代理；这种解决方式能启动，但治标不治本，不推荐在正式系统里大规模使用。

4.4 内存溢出与部署环境问题

本地跑项目内存溢出，通常有两种典型场景。

第一种是 Idea 启动项目时 OutOfMemoryError。如果日志里报 java: outofmemoryerror: insufficient memory，大概率是 Maven 或 IDE 的编译内存不足。可以在 IDEA 的 Help -> Change Memory Settings 里增大 IDE 内存；Maven 编译可以在 Maven 的 VM 参数里加上 -Xmx1024m。

第二种是数据量较大时 JVM 堆内存溢出。可以在启动参数里加上：

bash复制java -Xms256m -Xmx512m -jar health-shop.jar

-Xms 是初始堆大小，-Xmx 是最大堆大小。毕设项目这样配置足够用了。如果你把项目部署到服务器上，还要注意服务器内存本身是否足够，别在配置 -Xmx1024m 的情况下给一台只有 512MB 内存的服务器部署项目。

还有一个部署方面的问题：很多人在把 SpringBoot 项目打包成 jar 后运行 java -jar 时发现端口被占用，或者配置文件里的数据库连接不上，这不是代码问题，而是部署环境的配置文件问题。建议把 application.yml 中的数据库地址、Redis 地址等外部化配置，用环境变量或命令行参数覆盖，打包后通过 --spring.datasource.url=... 的方式传入，非常灵活。

4.5 前后端联调时的跨域问题

如果前端项目和后端接口分别跑在不同的端口上（比如前端 8080，后端 8081），跨域是必然遇到的。SpringBoot 解决跨域最简单的配置是写一个 CorsConfig：

java复制@Configuration
public class CorsConfig implements WebMvcConfigurer {
    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/**")
                .allowedOriginPatterns("*")
                .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS")
                .allowedHeaders("*")
                .allowCredentials(true)
                .maxAge(3600);
    }
}

注意这里用了 allowedOriginPatterns 而不是 allowedOrigins，因为 SpringBoot 2.4 之后 allowCredentials(true) 和 allowedOrigins("*") 不能同时使用，必须用 allowedOriginPatterns("*")，所以如果你在使用旧配置方式时报错，多半就是这个原因。

联调时还有一个很经典的坑：接口的 token 校验把所有请求都拦截了，包括预检请求 OPTIONS。这个解决办法是在拦截器里直接放行 OPTIONS 请求：

java复制if (HttpMethod.OPTIONS.toString().equals(request.getMethod())) {
    return true;
}

5. 答辩准备与项目扩展方向

5.1 答辩前需要准备的技术问题

毕设做完之后，答辩才是决定分数的那一步。基于我做项目评审的经验，老师最喜欢问的问题集中在几个方向。

“你这个项目的角色权限是怎么控制的？”这一问考察 Spring Security 和 JWT 的理解。你不需要背源码，但至少要说清楚 JWT 的生成、解析、校验流程，以及为什么需要加密密码存储。

“多个用户同时买同一个商品，库存只有 1 件，你怎么保证不会超卖？”这是最经典的高并发问题。回答思路是先说条件更新原子扣减，再说事务保证一致性，最后可以提一句“更进一步可以用 Redis 分布式锁或乐观锁”，把层次拉开。

“你的项目有哪些亮点？相比普通的商城系统，你做了什么特别的设计？”这个问题要提前准备。你可以说保健品的特殊字段设计、订单超时关单机制、状态机设计、图片上传白名单校验、密码加密存储等。

另外还有一个几乎必问的问题：“这个项目你做了多久？遇到的最大困难是什么？”这个问题回答的关键是体现解决问题能力的例子，比如跨域踩坑、循环依赖、事务失效等真实经历，而不是说“没遇到什么困难”。

5.2 这个项目还能怎么扩展

如果做完基础功能还有余力，或者想让项目在简历上更有竞争力，可以考虑以下方向。

第一个是 Redis 缓存改造。把商品详情、首页轮播这些热点数据缓存到 Redis 里，减少数据库压力。缓存更新时机可以选在商品上下架或管理员编辑商品时主动删除对应缓存。这也是能在简历上写“使用 Redis 缓存热点数据，QPS 提升 xx%”的素材。

第二个是 Elasticsearch 搜索。现有搜索是基于 MySQL 的 LIKE 模糊查询，数据量大了之后效率会下降。接入 Elasticsearch 以后可以实现更高效的商品全文检索。不过这个扩展成本比较高，除非你时间充裕否则不用强求。

第三个是消息队列。下单后发送短信通知、超时未支付关单，都可以用 RabbitMQ 的延迟队列来实现。就算不实际接入，也可以在设计文档里写清楚这个方案，在答辩时讲一讲“如果我做秒杀场景，会怎么设计系统”，会非常加分。

第四个是部署上线。用 Docker 把后端、前端、MySQL、Redis 分别打成镜像，用 Docker Compose 一键启动，再配个 Nginx 做反向代理。这一套完整的部署流程放在简历上很亮眼，同时也是从“能跑”到“能用”的关键一步。

5.3 给正在做这类项目的同学几个建议

最后分享几个实际做这类毕设项目的建议。

第一，代码写之前先花两个晚上把数据库表设计好。表设计定好了，整个项目的骨架也就定好了，后面写代码的顺畅程度完全取决于这一步。如果中间要改表，一定要同步把所有涉及到的代码改掉，不要只改 SQL 不改 Java。

第二，Git 从第一天就开始用。哪怕是单人开发，每天提交一次到 GitHub 或者 Gitee 也有好处：写坏了可以回滚，答辩时可以把提交记录展示给老师看，体现你的工程化习惯。很多老师确实会看这一块。

第三，写代码和写论文的时间分配大概是 6:4。很多同学把代码做完了才发现论文还没头绪。其实论文的框架在需求分析阶段就可以开始搭，每完成一个模块就补对应章节的图，到后期压力会小很多。

第四，不要过度追求“高级技术”。评审老师更在意的是你对自己做的东西能不能讲清楚。你用了 Redis 但讲不清缓存穿透和雪崩的区别，反而容易暴露短板。宁可做精一套完整的业务闭环，也不要堆砌一堆不熟悉的技术名词。