Spring Boot购物网站毕业设计实战：从技术选型到部署上线

1. 项目整体设计与技术方案选型

1.1 为什么“Spring Boot购物网站”能成为毕业设计经典选题

每年到了毕业季，计算机专业的同学都会面临同一个问题：选题。我在帮不少学弟学妹审题的时候发现，“Spring Boot购物网站”这个题目几乎年年出现，放在毕业设计源码库里也一直是热门编号。这个题目的生命力不在于它多新，而在于它足够“综合”——一个购物网站要把用户、商品、订单、购物车、支付、后台管理这些电商核心模块全部串起来，前后端交互、权限控制、数据库设计、并发处理、部署发布全都覆盖到了，恰好把大学四年学的知识串成了一条线。

大家别觉得这种题目“太普通”就随便应付。真正把它做扎实，需要你同时掌握Spring Boot自动装配原理、Spring Security的认证授权流程、MyBatis-Plus的CRUD封装逻辑、MySQL事务和索引优化，以及前端Vue或Thymeleaf的渲染机制。任何一个环节有缺失，开发到中途都会卡住。我见过太多人一上来就写代码，结果到订单模块就乱了套，因为表结构压根没设计好。

那源码编号“78960”这类东西只是个档案号，大家不用纠结具体数字。重要的是理解这个项目的骨架：它本质上是一个“用户前台+管理后台”的双端系统，前台面向普通消费者提供注册登录、商品浏览、购物车管理、订单提交，后台面向运营人员提供商品上下架、库存管理、订单处理、数据统计。这两个端用的是同一套Spring Boot服务，只是通过URL前缀和权限角色做了区分。

1.2 技术栈定版：版本选型就是第一个坑

先说版本，因为这是大多数新人第一个掉进去的坑。我复现过无数个Spring Boot项目，这里的教训非常统一：别用最新版，用稳定版，最好跟你参考的教程保持一致。Spring Boot从2.x升级到3.x，最大的变化是javax包名换成了jakarta，很多老代码直接编译报错。再加上3.x强制要求JDK 17，很多同学电脑上装的是JDK 8，一启动就报UnsupportedClassVersionError，然后整个人就懵了。

我这里给出一套经过大量实践验证的稳定组合：

有人会问，Spring Boot 3.x都出来那么久了，为什么还要用2.x？原因很简单：你的毕业设计不需要尝鲜，需要的是“稳”。3.x的坑太多了，比如Spring Security 6.0的配置方式完全变了，SecurityFilterChain替代了之前的WebSecurityConfigurerAdapter，网上能搜到的老教程大多失效。等你把这些问题都排干净，答辩日期都过去一半了。

我这里也提一句Spring Boot自动装配原理，因为这是面试必问，也是理解项目启动过程的关键。Spring Boot的自动装配核心在spring.factories或者META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports文件里，它声明了一堆XXXAutoConfiguration。启动时@EnableAutoConfiguration会通过SpringFactoriesLoader加载这些配置类，再用@ConditionalOnProperty、@ConditionalOnClass等条件注解判断是否生效。这就是为什么你引入spring-boot-starter-web后，只需要一个@SpringBootApplication就能把Tomcat、DispatcherServlet、Jackson全给你配好。

1.3 单体架构还是前后端分离：别一上来就搞微服务

购物网站这个题目，很多人会纠结要不要拆微服务、要不要用Spring Cloud。我的建议非常明确：毕业设计千万别碰微服务，安安分分做单体架构。微服务虽然听起来高大上，但引入Nacos注册中心、OpenFeign远程调用、Sentinel限流、分布式事务Seata之后，你需要解决的就不再是业务问题，而是分布式环境下的各种复杂故障。这些内容放到论文里确实漂亮，但以本科毕设的时间线，很容易把自己拖垮。

单体架构下，Spring Boot作为一个核心服务，既可以自己同时渲染页面，也可以对外提供RESTful API。如果你前端基础弱，建议用Thymeleaf模板引擎做服务端渲染，一个依赖就能搞定，不用折腾跨域；如果你前端能力还行，想用Vue做一个漂亮点的前台页面，那就用前后端分离方案，Spring Boot提供/api/user/**、/api/goods/**这类接口，Vue这边通过Axios发请求。

我个人更推荐前后端分离。原因在于论文写起来层次更清晰，你可以明确划分“前端展示层-后端接口层-数据持久层”，答辩时老师问起来，你也有个清晰的架构图可以讲。不过分离方案要给前端页面找一个容器，可以选择把Vue打包后的静态资源放到Spring Boot的static目录下，也可以单独用Nginx部署，后者更加规范。

2. 需求拆解与数据库建模

2.1 购物网站的功能边界：先画清楚，再写代码

一个购物网站的功能列表看似简单，实际上要拆得很细。我在这里列一个标准的毕业设计功能清单，大家直接对照自己的项目查漏补缺：

前台用户端：

• 用户注册与登录：用户名密码登录、手机号/邮箱验证码登录、退出登录
• 商品浏览：首页商品推荐、分类导航、商品搜索（关键字/分类/价格区间过滤）、商品详情页
• 购物车：加入购物车、修改数量、删除、批量结算
• 订单：提交订单、订单列表、订单详情、取消订单、确认收货
• 个人中心：资料修改、密码修改、收货地址管理、订单记录
• 辅助功能：轮播图、公告、收藏

后台管理端：

• 管理员登录认证
• 用户管理：查看用户列表、禁用/启用用户
• 商品管理：添加商品、编辑商品、上下架、库存管理、商品图片上传
• 分类管理：商品分类的增删改查
• 订单管理：订单列表、发货、查看订单详情、统计每日订单量
• 数据统计看板：近七天销售额、热门商品TOP10

需要注意的是，毕业设计不需要做真实支付。你接支付宝沙箱或者微信支付沙箱可以做，但不接也完全不影响评分。很多学校其实不希望你们真的接入支付，因为涉及企业资质和隐私问题。你可以在订单状态机里加上“已支付”这个状态，然后后台上提供一个“模拟支付”按钮，或者直接默认下单即视为已支付，这样就绕开了支付环节。

2.2 核心数据表设计：耦合关系想清楚再建表

数据库建模是整个项目的地基，表结构设计好了，后面写代码就是流水线作业；表结构设计烂了，后面就是无穷无尽的修补。我强烈建议大家在写任何一行代码之前，先把数据库建好。

购物网站最少不要少于这几张核心表：

这里要注意两个容易被忽略的设计点。

第一，订单明细表为什么要冗余商品名称和图片。因为商品信息是会变的，今天这件T恤叫“纯棉白色圆领T恤”，明天可能就改成“夏季爆款白色T恤”了，但你历史订单里的商品名称不能跟着变，你得记录下单那一刻的快照。这就是为什么order_item里要有goods_name和goods_image，而订单查询时不能去关联goods表实时查。

第二，订单号不要用自增ID。订单号需要唯一且不容易被猜到，直接用自增主键就暴露了你的订单量。推荐用“时间戳+随机数生成业务订单号”的模式，比如yyyyMMddHHmmss + 4位随机数。要注意的是，订单号是在并发场景下生成的，随机数范围太窄或者生成逻辑不加分布式锁，很容易碰撞，所以要在订单号字段上建唯一索引兜底。

2.3 表设计里的索引与状态字段约定

数据库索引不用铺太多，但关键查询路径必须覆盖。我的习惯是：user表的username建唯一索引，goods表的category_id建普通索引，orders表的user_id建普通索引，order_no建唯一索引，cart表的user_id和goods_id建联合索引。然后商品搜索场景如果需要按价格排序，可以在price字段上加索引，这个看数据量。实际开发中，一个表索引太多会拖慢写入性能，太少又会让查询走全表扫描，取舍的依据是“这个查询是不是高频、是不是在核心链路上”。

状态的字段约定也要提前统一。比如订单状态，我建议用整数而不是字符串：

• 0 = 待付款
• 1 = 待发货
• 2 = 待收货
• 3 = 已完成
• 4 = 已取消

用整数的好处是状态流转清晰、排序方便、数据库占空间小。如果你用字符串“PENDING”、“PAID”、“SHIPPED”这种英文枚举，可读性高但写起来麻烦，而且如果前后端约定的字符串大小写不一致，就很容易出bug。我个人的习惯是数据库和Java枚举都定义好，Java这边用一个OrderStatusEnum把这些值统一管理，业务代码里不允许出现魔法数字。

3. 核心功能实现与关键原理拆解

3.1 登录认证：从Session到JWT，权限模型要选对

购物网站的登录认证是第一个核心功能，也是体现项目技术含量的地方。这里有两种主流做法：传统Session方案和JWT无状态方案。毕业设计我推荐JWT方案，一是因为Spring Boot + Vue前后端分离场景下JWT是标配，不用处理Session共享问题；二是因为JWT的认证流程“请求带token → 服务端验证 → 解析用户信息”非常清晰，答辩时好讲。

JWT的登录流程是这样的：用户提交用户名密码，后端校验通过后生成一个Token返回给前端。前端把Token存在localStorage或者Vuex/Pinia里，之后每次请求在请求头加上Authorization: Bearer <token>。后端通过拦截器或者Spring Security过滤器链解析Token，验证合法性和过期时间，取出里面的userId，然后把这个请求放行到Controller层。

实际开发中，生成Token建议用jjwt库，依赖很少，代码也很简洁：

java复制public String generateToken(User user) {
    long now = System.currentTimeMillis();
    long expireTime = now + 7 * 24 * 60 * 60 * 1000; // 7天过期
    return Jwts.builder()
            .setSubject(user.getUsername())
            .claim("userId", user.getId())
            .setIssuedAt(new Date())
            .setExpiration(new Date(expireTime))
            .signWith(SignatureAlgorithm.HS512, secretKey)
            .compact();
}

注意一点：JWT的signWith的密钥不能写死在代码里，应该放到application.yml配置文件中，用@Value注入。这个密钥长度不能太短，HS512要求密钥不少于64字节，否则WeakKeyException会直接把你启动过程打断。

如果你用的是Spring Security，不是自己想怎么拦截就怎么拦截。Spring Security 5.x的配置方式不需要继承WebSecurityConfigurerAdapter，而是定义一个SecurityFilterChain：

java复制@Bean
public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
    http.csrf().disable()
        .sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS)
        .and()
        .authorizeRequests()
        .antMatchers("/api/user/login", "/api/user/register", "/api/goods/**").permitAll()
        .antMatchers("/api/admin/**").hasRole("ADMIN")
        .anyRequest().authenticated();
    return http.build();
}

同时，为了能在Controller里方便地拿到登录用户ID，建议自定义一个HandlerMethodArgumentResolver，从Token里解析出userId后注入到@RequestAttribute或者自定义的@LoginUser User user参数里，这样每个接口不用重复写解析Token的逻辑。

3.2 商品与购物车：缓存和数据库的一致性怎么处理

购物车模块看起来简单，无非是增删改查，但它非常能体现一个人对数据的理解程度。购物车的一个关键点是“要不要存Redis”。如果只存在MySQL里，数据可靠，但每次请求都查数据库，用户对购物车频繁操作时性能一般。如果存在Redis里，性能好，但Redis挂掉或者过期，用户购物车就丢了，体验很差。

我这里给一个折中的思路：购物车以数据库为准，Redis只做热点缓存。具体来说是，用户在详情页点击“加入购物车”时，先写入MySQL，然后同步更新Redis中的购物车哈希结构；查询购物车列表时，优先读Redis，缓存未命中再查数据库回填。这个方案兼顾了可靠性和性能，代码也不复杂。

加购的Service层伪代码可以这样写：

java复制@Transactional(rollbackFor = Exception.class)
public void addToCart(Long userId, Long goodsId, Integer quantity) {
    Goods goods = goodsService.getById(goodsId);
    if (goods == null || goods.getStock() < quantity) {
        throw new BusinessException("商品库存不足");
    }
    Cart cart = cartMapper.selectOne(new LambdaQueryWrapper<Cart>()
        .eq(Cart::getUserId, userId)
        .eq(Cart::getGoodsId, goodsId));
    if (cart == null) {
        cart = new Cart();
        cart.setUserId(userId);
        cart.setGoodsId(goodsId);
        cart.setQuantity(quantity);
        cartMapper.insert(cart);
    } else {
        cart.setQuantity(cart.getQuantity() + quantity);
        cartMapper.updateById(cart);
    }
    // 同步刷新Redis
    CartDTO cartDTO = new CartDTO(cart, goods.getPrice(), goods.getGoodsName());
    redisTemplate.opsForHash().put(CART_KEY + userId, String.valueOf(goodsId), JSON.toJSONString(cartDTO));
}

注意，这个@Transactional注解很关键。购物车操作涉及“查库存→写购物车”，两步之间如果有并发操作，可能出现超卖。在毕设项目里，用数据库事务配合行级锁就可以解决绝大部分问题。如果你想把性能做上去，可以先用SELECT ... FOR UPDATE锁住商品行，再判断库存，但这个写法在事务里要小心死锁，建议所有加购操作都按照“userId→goodsId”的顺序加锁。

商品详情页的热点数据还可以用Redis缓存优化。商品浏览量越高，越应该缓存。我用的策略是：详情页先查缓存，命中直接返回；没有命中则查数据库，然后手动填充缓存，设置过期时间比如10分钟。这样商品一旦被修改，最多10分钟后前端的详情页才更新，后台编辑商品时调用deleteObject("goods:" + goodsId)清掉缓存即可。

3.3 订单模块：事务边界与状态机设计

订单模块是整个购物网站里最复杂的模块，也往往是答辩时老师重点追问的地方。它的核心难点在于：下单这个动作要同时操作多张表，任何一个步骤失败，整个订单都不能成立。

标准的下单流程是：

1. 校验购物车勾选商品、校验库存
2. 创建订单主记录（状态：待付款）
3. 批量创建订单明细记录
4. 扣减库存
5. 清空选中的购物车记录
6. 返回订单号

这六步必须在一个数据库事务里完成，否则就会出现“订单创建了但库存没扣”或者“库存扣了但购物车没清空”的脏数据。Spring Boot里使用@Transactional注解可以搞定事务，但有几个细节要特别注意。

第一，事务内不要捕获异常。如果你在事务方法里用try-catch把异常吞掉了，Spring就感知不到异常，不会触发回滚。正确做法是抛出RuntimeException，或者使用rollbackFor = Exception.class对受检异常也回滚。

第二，扣库存的SQL必须写条件判断。别用“先查再改”的写法：

java复制// 错误示范：先查询库存，判断后再扣减
Goods goods = goodsMapper.selectById(goodsId);
if (goods.getStock() >= quantity) {
    goods.setStock(goods.getStock() - quantity);
    goodsMapper.updateById(goods);
}

这种写法在并发环境下必出超卖。正确做法是把“库存充足”作为UPDATE语句的条件：

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

UPDATE影响行数为1说明扣减成功，为0说明库存不足，需要抛异常提示。这就是原子操作的好处，SQL引擎保证“判断+修改”在同一瞬间完成，不需要加锁也不会有并发漏洞。

第三，订单撤销与超时处理。很多购物网站有“30分钟未支付自动关单”的机制，毕设里不一定要求做到，但你可以做一个简单版：用户提交订单后如果选择“取消”，后端调用取消接口，把订单状态改成已取消，然后把商品库存回补。这个回补库存的操作必须跟订单状态更新放在同一个事务里，否则会出现订单取消但库存变不回来的bug。

3.4 后台管理和文件上传：用MyBatis-Plus简化开发

后台管理模块的开发量大头在CRUD，所以务必用好MyBatis-Plus。它的核心优势是内置了BaseMapper<T>，你只需要定义一个实体类和一个Mapper接口，基础的增删改查方法就全有了。节省的时间不是一点点。

商品管理的实体类可以这样定义：

java复制@Data
@TableName("goods")
public class Goods {
    @TableId(type = IdType.AUTO)
    private Long id;
    private Long categoryId;
    private String name;
    private String subtitle;
    private String mainImage;
    private BigDecimal price;
    private Integer stock;
    private Integer sales;
    private Integer status; // 1-上架，0-下架
    private LocalDateTime createTime;
    private LocalDateTime updateTime;
}

有了这个实体类，分页查询商品列表只需要一行代码：

java复制Page<Goods> page = goodsMapper.selectPage(
    new Page<>(current, size),
    new LambdaQueryWrapper<Goods>()
        .eq(StringUtils.isNotBlank(categoryId), Goods::getCategoryId, categoryId)
        .like(StringUtils.isNotBlank(keyword), Goods::getName, keyword)
        .eq(status != null, Goods::getStatus, status)
        .orderByDesc(Goods::getCreateTime)
);

LambdaQueryWrapper的每个条件前面加了boolean判断，就是为了处理“这个参数传没传”的问题。这样写比拼SQL清晰得多，也比XML文件方便维护。

商品图片上传也是个绕不开的功能。Spring Boot默认的单文件上传大小限制是1MB，随便传一张高清商品图就会被拦截。所以必须要在application.yml里扩大限制：

yaml复制spring:
  servlet:
    multipart:
      max-file-size: 10MB
      max-request-size: 20MB

文件上传后存储到哪里也是个问题。本地磁盘存到D:/upload/或者/usr/local/upload/，然后通过一个映射路径暴露给你访问。但更好的做法是使用MinIO或者阿里云OSS。如果你不想额外折腾，在本地用WebMvcConfigurer做一个静态资源映射即可：

java复制@Configuration
public class StaticResourceConfig implements WebMvcConfigurer {
    @Override
    public void addResourceHandlers(ResourceHandlerRegistry registry) {
        registry.addResourceHandler("/upload/**")
                .addResourceHandler("file:D:/upload/");
    }
}

这里有一个传输经验：把文件存储路径放在配置文件里，而不是写死在代码中。因为本地Windows路径和Linux服务器路径不一样，写死很容易在部署阶段出现问题。

4. 项目部署与常见问题排查实录

4.1 Spring Boot版本兼容性：我踩过的那些“坑”

前面提到过版本选择的问题，但实际开发中，版本冲突远不止“Spring Boot 3.x不能用JDK 8”这一件事。这里我把项目开发过程中容易踩的版本坑集中说一下，都是真实遇到过的。

第一，MyBatis-Plus版本要和Spring Boot版本匹配。MyBatis-Plus 3.4以下的版本对Spring Boot 2.4以上的支持不完善，启动时可能报Invalid value type for attribute 'factoryBeanObjectType'。推荐统一用MyBatis-Plus 3.5.x，它同时适配Spring Boot 2.7和3.x的微调，兼容性最稳。

第二，MySQL驱动的URL变化。Spring Boot 2.6.x自动管理MySQL驱动版本，如果你连的是MySQL 8.0，连接串要加serverTimezone=Asia/Shanghai和useSSL=false，否则启动时报“The server time zone value”错误。如果你是MySQL 5.7，驱动类名用com.mysql.jdbc.Driver，注意不要误用8.0的com.mysql.cj.jdbc.Driver。实际上Spring Boot在2.7.x已经把MySQL驱动版本锁定到了8.x，所以即使你连5.7的库，驱动类名也统一写com.mysql.cj.jdbc.Driver就对了。

第三，Lombok版本过低导致编译失败。很多新手从网上下载了一份老项目，里面Lombok版本是1.16.x，配合新版的Maven编译器时，会出现java.lang.ExceptionInInitializerError，原因就是Lombok版本跟JDK版本不兼容。换成1.18.30基本能解决所有问题。

第四，Redis Lettuce连接池报错。Spring Boot 2.x默认使用Lettuce作为Redis客户端，高并发下会出现RedisConnectionFailureException。但是毕业设计的访问量根本达不到触发这个问题的量级，你只需要在配置里加上连接池参数：

yaml复制spring:
  redis:
    lettuce:
      pool:
        max-active: 8
        max-idle: 8
        min-idle: 2

4.2 循环依赖：一个让新手头疼的启动失败

循环依赖是Spring Boot项目里出现频率极高的启动报错。比如GoodsService依赖CategoryService，而CategoryService又依赖GoodsService，就会形成一个环。Spring Boot 2.6版本开始默认禁用了循环依赖，项目启动时直接报错：The dependencies of some of the beans in the application context form a cycle。

解决循环依赖有三种思路：

1. 重新设计Service层依赖关系。大多数循环依赖是代码分层没做干净导致的。比如GoodsService需要调用分类名称，CategoryService又需要查商品数量来展示。这个场景下，你可以在GoodsService中注入CategoryMapper，或者干脆在GoodsVO里冗余一个分类名字段，在需要时直接用Mapper查询，从源头打破循环。

2. 使用@Lazy注解延迟注入。这个方案能解决启动问题，但治标不治本。@Lazy会让Spring在第一次调用时才创建代理对象，把“创建Bean”这个时机延后了，代码运行时如果代理对象初始化失败，问题更加隐蔽。所以只在紧急情况下用，不建议作为长期方案。

3. 把公共逻辑抽离到独立的Service。比如商品和分类都需要库存变化通知、都需要生成编号，可以抽一个GoodsStockService或者CommonDataService，让商品Service和分类Service都依赖它，而不是互相依赖。

实际上，Spring Boot 2.6以后我从来不去关闭循环依赖检查，因为关闭之后框架绕过了Bean生命周期的管理，容易留下隐性故障。遇到循环依赖，优先做代码重构。

4.3 Spring Boot打包到Docker Desktop的完整流程

这几年越来越多的学校要求项目用Docker部署，答辩的时候能现场启动一个容器绝对加分。这里直接给出一套在Windows环境上安装Docker Desktop并部署Spring Boot项目的完整流程。

Docker Desktop对版本要求蛮敏感的，不是所有Spring Boot项目都能直接塞进容器，核心问题在镜像的JDK版本上。如果你本地用的是JDK 8编译，但Dockerfile里写的是FROM openjdk:17，那启动的时候必然会报UnsupportedClassVersionError。反过来也一样。所以Dockerfile的JDK版本必须和编译版本保持一致。

我用的Dockerfile长这样：

dockerfile复制FROM openjdk:8-jdk-alpine
VOLUME /tmp
COPY target/shopping-mall-0.0.1-SNAPSHOT.jar app.jar
ENV JAVA_OPTS="-Xms256m -Xmx256m"
ENTRYPOINT ["java", "-jar", "/app.jar"]

打包和构建的命令分两步：

bash复制mvn clean package -DskipTests
docker build -t shopping-mall:1.0 .

Docker Desktop的坑主要在内存设置。默认分配2GB内存，Spring Boot项目加上MySQL的容器很容易OOM。建议在Docker Desktop的Settings → Resources里把内存调到4GB以上。还有一个就是文件共享目录，Docker要访问你Windows的target目录或者D:/upload/目录，必须先在Settings → Resources → File sharing里把对应盘符加进去，否则启动时会报“file not found”。

如果你想把MySQL也放到容器里跑，可以用docker-compose把两个服务编排起来，这样一条命令启动所有服务：

yaml复制version: '3'
services:
  mysql:
    image: mysql:5.7
    environment:
      MYSQL_ROOT_PASSWORD: root123
      MYSQL_DATABASE: shopping_mall
    ports:
      - "3306:3306"
    volumes:
      - ./mysql-data:/var/lib/mysql
  app:
    build: .
    ports:
      - "8080:8080"
    depends_on:
      - mysql

这样部署之后，本地访问localhost:8080就是你的购物网站，可复现性很高。唯一要注意的是，application.yml里的数据库连接地址要改成jdbc:mysql://mysql:3306/shopping_mall，因为容器内服务名mysql就是主机名。否则应用容器连数据库时会连到本地的3306，两个同端口服务会冲突。

4.4 常见问题速查表：一天一个排查小技巧

我把做毕业设计过程中最容易遇到的报错和解决办法整理成一张表，方便大家报错时快速定位。

这里再分享一条排查经验：遇到问题先看日志，而不是直接去搜索引擎。Spring Boot的日志已经非常详细了，一般异常信息里就带着解决问题所需的所有线索。你要学会看堆栈的第一行和最后一行——第一行告诉你发生了什么异常，最后一行告诉你发生在哪一行代码。把这两个信息看明白，再决定怎么搜，效率会高很多。

关于Spring Boot单元测试，也值得多说一句。很多毕设项目完全没有单元测试，答辩时老师问一句“你怎么保证代码正确性”你就哑口无言了。其实Spring Boot写单元测试非常简单，加一个spring-boot-starter-test依赖，然后对Service层的核心逻辑写几个测试用例就行。比如对订单状态流转测试，对库存扣减的并发安全测试。哪怕你只写了十几个用例，也至少能证明你对测试有意识，这在答辩时是加分的。

5. 从毕业设计到简历项目：还能再扩展点什么

5.1 给项目加一个技术亮点，拉开差距

说实话，“Spring Boot购物网站”这个题目太常见了，答辩现场十个人可能有六个人做的是类似题目。所以除非你在功能或技术上做出了明显的差异化，不然老师很难记住你。我建议在基础功能完成之后，往下面这几个方向挑一个做深一点。

第一个方向是搜索优化。普通的商品搜索是用WHERE name LIKE '%keyword%'实现的，数据量大了以后性能很差。你可以引入Elasticsearch来做商品搜索，把商品数据同步到ES里，搜索直接查ES。这是电商系统的经典玩法，而且Elasticsearch在简历上属于加分技能。不过要注意，引入ES后服务部署的复杂度会上升，建议作为扩展功能单列，不要影响主流程。

第二个方向是接口限流与缓存优化。你可以用Redis做接口访问频率限制，比如登录接口1分钟只能请求5次，防止暴力破解。商品详情页用Redis做热点缓存，已经被高频访问的商品直接读缓存，不用查询数据库。这两个功能实现起来都不复杂，但写进论文里可以作为一个“性能优化”章节，比单纯堆功能有含金量得多。

第三个方向是引入消息队列。你可以在订单模块引入RabbitMQ，下单成功后把订单信息发到队列，后台系统监听队列做库存扣减后的日志记录或短信通知。这种异步解耦思想是互联网高并发架构的核心，也是面试高频考点。唯一的风险是RabbitMQ的安装和配置可能会花费时间，但如果你电脑上已经装好了，那实现成本其实很低。

5.2 功能扩展的实际案例：热词里的“上传下载大文件”

我看到最近有很多人在搜“Spring Boot如何上传下载大文件”，这里也顺便说一嘴。如果购物网站后期需要支持商家上传商品介绍视频或者高清图片包，那么用普通的MultipartFile上传几GB文件就会内存溢出。Spring Boot的解决思路是分片上传：前端把文件切成1MB大小的分片，一个接一个上传，后端收到后存储为临时分片文件，全部传完后合并。后端需要提供一个“合并分片”的接口，才能保证文件完整性。

分片上传接口的伪代码可以这样理解：

java复制@PostMapping("/api/upload/chunk")
public Result uploadChunk(@RequestParam("file") MultipartFile file,
                          @RequestParam("identifier") String fileId,
                          @RequestParam("chunkNumber") Integer chunkNumber) {
    // 将分片写入临时目录
    File tempDir = new File(uploadPath + "/" + fileId);
    if (!tempDir.exists()) tempDir.mkdirs();
    file.transferTo(new File(tempDir, chunkNumber + ".part"));
    return Result.ok();
}

合并的时候按分片序号排序，用Files.copy把每个分片追加写入目标文件，全部合并完再删除临时目录。这个功能做出来以后，比普通文件上传要“高级”一个档次，放在项目里是明确的技术亮点。

5.3 我的一点项目扩展观察

还有一点想跟大家提的，是很多同学纠结的“要不要做App端”。购物网站毕设一般是Web端，但如果你的精力允许，可以做一个简单的移动端H5适配，或者用微信小程序套壳一个前端页面。技术上来说，后端接口不变，前端页面复用一部分，工作量不会特别大。但我不建议在毕设前期就启动移动端，因为核心功能没做完之前，任何扩展都是耍流氓。等Web端全部稳定了，再决定要不要加。

从简历角度说，一个项目有两个亮点就够讲了，不是功能越多越好。你要能讲清楚每个功能背后的技术选型思路、实现难点和解决过程，这些才是面试官真正想听的。

6. 最后分享几个让答辩更顺利的实战经验

6.1 演示数据要提前准备好

答辩现场最尴尬的事情，就是演示到一半发现商品列表是空的。你提前要在数据库里准备一套完整的演示数据：至少20个商品，分布在5个分类里；每个商品要有清晰的主图和详情图；购物车里预置两条记录；订单列表里要有不同状态的订单，方便展示“待发货”“待收货”的状态流转。这套数据建议写一个SQL初始化脚本文档，放到项目源码的db目录下，这样老师看到你的项目结构时，会觉得你很规范。

6.2 线上演示和本地的环境尽量一致

如果有条件，答辩前一天把项目打包成可执行Jar包，或者配好Docker Compose，在答辩现场一键启动。不要等到现场临时用IDEA启动，因为IDEA的构建过程可能会因为网络、依赖下载等问题卡住。我见过太多人答辩的几分钟全浪费在等Maven下载依赖上了。提前把环境跑通，这是对答辩最大的尊重。

6.3 关于“源码”这件事，别做搬运工

最后想说一个关于“源码”的观察。网上到处可以搜到Spring Boot购物网站的源码，很多人下载下来改个名字就交了。这是非常危险的做法。第一，很多网上的源码自带后门或者恶意代码，前几年就有大学生用网上下载的毕业设计源码，结果数据库被删、论文被人加密勒索的案例。第二，即便你能跑通，答辩时老师只要深问一个问题，比如“你这个购物车的并发控制怎么做的”“你这个订单状态机是怎么设计的”，你答不上来，反而比不做更糟糕。真正把项目亲手做一遍，哪怕功能简单一点，你在答辩时的底气是完全不同的。

我在实际做项目过程中的体会是：这个购物网站项目最难的不是某个单独的技术点，而是把所有模块串联起来时的逻辑一致性。你改了商品模块的字段，订单模块是否跟着改？你加了用户角色，权限控制是否覆盖到了后台所有接口？这些联动问题，只有把代码完整走一遍才能真正体会。所以拿到任何源码，我建议你在读懂的前提下，亲手把核心模块重写一遍，哪怕只重写登录和订单两个模块，也足以让你对项目有真正的掌控感。

最后再分享一个小技巧：给项目里的每个接口写一个简短的API说明，用Swagger或者Postman的文档功能都可以。答辩时老师非常喜欢问“你这个接口返回什么字段”“异常怎么处理”，有了接口文档，你回答这些问题会游刃有余得多。这个习惯，也会让你在以后的工作中受益匪浅。