基于Java+SpringBoot的闲置品交易平台：毕业设计完整实现

先说说这个项目，讲真，每年到毕业季，我都会收到大量私信问“毕设做什么题目好”。很多同学一上来就想要那种听起来很高级的题目，什么“基于深度学习的某某系统”、“基于微服务的某某平台”，但实际做起来要么被复杂的技术栈劝退，要么做到一半发现数据根本搞不定。而我今天要聊的这个项目——“基于Java+SpringBoot的闲一品闲置品交易平台”，反而是我见过最适合绝大多数本科生的选题方向之一。

它不装、不炫技，但完备地覆盖了一个真实项目该有的核心要素：用户体系、商品管理、交易流程、订单状态机、支付（或模拟支付）、消息通知、后台管理，以及一系列工程化细节。而且SpringBoot这套技术栈在就业市场上依旧是绝对的主流，简历上写这个项目，面试官不会觉得陌生，也容易聊出深度。

这篇内容我打算从选题思路、方案设计、核心模块拆解、实操过程、常见问题排查这几个维度来讲，尽量还原我当时辅导学生做同类型项目的完整过程。无论你是完全没做过项目的萌新，还是已经有基础想找一个毕业设计题目的老手，这篇都应该能给你一些实际的启发。文章挺长，我更建议把它当一份参考资料来用，需要做某个部分的时候回来看一眼，比从头读到尾效率更高。

1. 项目整体设计与思路拆解

1.1 为什么“闲置品交易平台”是毕业设计的“安全牌”

选题这件事，是毕业设计的第一个分水岭。每年都有人挂在选题上——题目太复杂，半年做不完；题目太偏门，老师不认可，资料也少；题目太大，写论文的时候根本收不住。闲置品交易平台这个方向，恰好卡在一个非常舒服的位置。

先说市场背景，二手交易和闲置流转已经不是小众需求了，市面上从综合类的“闲鱼”到垂直类的“转转”“多抓鱼”，很多人都用过这类产品。正因为如此，这个题目天然带着“需求真实”的属性。写开题报告的时候，你不需要费劲解释这个平台解决了什么痛点——你自己身边就有大把例子：毕业季学长学姐的教材和台灯、宿舍里用不上的小家电、考研结束后的复习资料，这些东西丢之可惜、留之无用，一个校内闲置平台就能让它们重新流动起来。

再从技术适配性来看，一个典型的校园闲置品交易平台，核心链路就是“用户注册登录——发布商品——浏览搜索——下单购买——订单状态流转——交易完成评价”。这中间需要的技术能力，SpringBoot + MyBatis-Plus + MySQL + Redis + Vue这套组合拳就能完全覆盖，不涉及高并发、不涉及海量数据、不涉及分布式事务，但对于理解Web全栈开发、理解数据库设计和后端工程组织来说，这个题目的信息量恰好是满的。

最后从答辩角度讲，这种系统容易讲清楚。你不需要对着PPT讲一堆玄乎的算法，只需要把业务流程画清楚，把核心模块的代码逻辑讲明白，把几个技术难点的解决方案说透彻，答辩老师自然会给你一个合理的评价。很多同学担心“没有亮点”会被问到哑口无言，但恰恰相反，平庸的系统配合扎实的理解，一定要比花哨的系统配合含糊的讲解更有说服力。

1.2 技术选型背后的逻辑：围绕“能落地”来取舍

这个项目我最终锁定的技术栈是这样的：

• 后端：JDK 1.8 + SpringBoot 2.7.x + MyBatis-Plus 3.5.x
• 数据库：MySQL 5.7 + Redis
• 前端：Vue 2 + Element UI + Axios
• 构建工具：Maven
• 其他：JWT（无状态登录）、OSS（对象存储，也可用本地存储替代）、WebSocket（站内消息）

为什么刻意选这些组合，我一个个说。

SpringBoot 2.7.x而不是3.x，这里有个很现实的原因：第三方生态兼容性。SpringBoot 3.0是2022年底发布的，它基于Java 17和Jakarta EE，很多老的依赖如果没跟上，很容易出现类找不到或者包名对不上的问题。对于毕业设计这种求稳的场景，2.7.x配合JDK 1.8是最成熟的组合，网上教程最多、遇到问题最好搜、几乎所有云服务器都能轻松跑起来。

MyBatis-Plus 选它不是因为比JPA高级多少，而是因为它真的“省事”。单表CRUD几乎不用写SQL，内置的分页插件一行代码搞定，代码生成器还能根据数据库表自动生成实体类、Mapper、Service、Controller一整条链路的代码。所以基础版代码可以靠它快速成型，剩下的精力全部集中在业务逻辑和边角打磨上。

前端为什么用Vue 2而不是Vue 3？倒不是说Vue 3不好，而是Element UI这套组件库和Vue 2的搭配太成熟了。网上的后台管理系统模板、权限控制方案、表格表单封装，绝大多数都是Vue 2 + Element UI的组合。对于毕设这种工期紧张、需要快速出效果的项目，选成熟方案比选新方案重要得多。

存储这块，图片上传我建议优先考虑OSS。不过有些同学可能没有云服务账号，或者不想花钱，那就用本地存储——把图片存到项目里的upload目录，然后把静态资源映射出来。两种方式我在后面第三节都会给出具体的实现方案。

1.3 功能模块的全貌：一个“麻雀虽小五脏俱全”的闭环

很多人做毕设容易犯一个错误：功能列表写得无比丰满，什么“智能推荐”“大数据分析”“区块链存证”都往上堆，结果开发的时候根本hold不住。实际上一个好的毕设系统不需要特别大的功能量，重要的是功能之间有逻辑闭环，数据流转是完整的、自洽的。

我建议的模块划分是这样的：

• 用户端（前台）：

  • 注册登录（手机号/邮箱 + 密码，集成JWT）
  • 商品浏览（关键词搜索、分类筛选、分页展示）
  • 商品详情页（图文展示、卖家信息、收藏、留言咨询）
  • 发布商品（封面图上传、标题描述、价格分类设置）
  • 订单管理（确认购买、取消订单、确认收货、退货申请）
  • 个人中心（发布的商品、买到的商品、卖出的商品、收藏夹、站内消息）

• 管理端（后台）：

  • 管理员登录
  • 用户管理（禁用/启用用户）
  • 商品审核（上架/下架/删除违规商品）
  • 分类管理（增删改查商品分类和轮播图）
  • 订单管理（全局订单查看、异常订单处理）
  • 数据统计（用户数、商品数、订单量等基础指标）

这个功能列表不贪多，但每一块都有存在的必要性。用户端到管理端的数据是联通的：用户发布商品后进入待审核状态，管理员审核通过才对外展示；订单状态每一步变化都会生成消息通知到相关用户；后台统计的数据来源就是业务表本身。这个“联通性”恰恰是答辩的时候回答“为什么这么设计”的关键材料。

2. 核心细节解析与实操要点

2.1 数据库设计：提前理清表关系，后面少走弯路

数据库设计是这类项目的灵魂。即使代码写得再漂亮，表设计不合理的话后面就是无穷无尽的补丁逻辑，造各类奇怪的数据。我通常建议先画E-R图（实体关系图），把核心实体和关联关系捋清楚再落表。这个项目的核心实体大概有这么几个：

• 用户表（user）：用户ID、用户名（昵称）、密码（加密存储）、手机号、头像、学校/地址、状态、注册时间
• 商品表（product）：商品ID、卖家ID（外键到用户表）、分类ID、标题、描述、价格（用Decimal类型）、封面图、成色（九成新/八成新等）、所在地、状态（待审核/在售/已售下架）、浏览量、发布时间
• 订单表（orders）：订单ID、商品ID、买家ID、卖家ID、订单状态（待付款/已付款/已发货/已完成/已取消）、下单时间、付款时间、完成时间、订单号（唯一）
• 收藏表（favorite）：ID、用户ID、商品ID、收藏时间
• 留言/咨询表（message）：ID、商品ID、发送者ID、接收者ID、内容、时间
• 分类表（category）：分类ID、分类名称、排序、是否启用
• 轮播图表（banner）：ID、图片URL、链接、排序、状态
• 通知/站内消息表（notice）：ID、发送者/接收者、类型（系统/订单/互动）、内容、是否已读、时间

一个特别要注意的坑是：金额字段一定不要用float/double。浮点数在二进制表示里天然存在精度问题，做金额计算的场景必须用Decimal，这个考点几乎年年出现在面试题里，毕设里用了double算金额，面试官一问就会暴露。

还有一个实用的设计技巧：订单表里同时存买家ID和卖家ID，而且订单状态单独用一个字段标注。不要想着去商品表里反查卖家，那样业务逻辑会变得非常绕，SQL也不好写。

2.2 用户认证：JWT无状态登录比Session省心太多

老一套的后端登录方案是Session，服务端保存登录状态，客户端拿一个JSESSIONID cookie。这套方案在教学里很常见，但说实话在前后端分离的架构里很别扭——跨域要处理cookie、分布式环境要引入session共享方案，全是麻烦。

这个项目我直接用JWT（JSON Web Token）。原理不复杂：用户登录的时候，服务端验证账号密码无误后，把用户ID、手机号、过期时间这些信息经过签名生成一个token字符串返回给前端。前端每次请求的时候把这个token放在请求头里带回来，后端用一个拦截器解析token，解析成功就认为用户已登录，并从token里拿到当前用户ID。

具体实现上我推荐用jjwt这个库，版本0.9.1配合JDK 1.8没有任何兼容性问题。生成token的代码大致是：

java复制public String generateToken(Long userId, String phone) {
    return Jwts.builder()
            .setSubject(phone)
            .claim("userId", userId)
            .setIssuedAt(new Date())
            .setExpiration(new Date(System.currentTimeMillis() + EXPIRE_TIME))
            .signWith(SignatureAlgorithm.HS256, SECRET_KEY)
            .compact();
}

解析token并获取用户ID的代码：

java复制public Long getUserIdByToken(String token) {
    Claims claims = Jwts.parser()
            .setSigningKey(SECRET_KEY)
            .parseClaimsJws(token)
            .getBody();
    return claims.get("userId", Long.class);
}

在SpringBoot里做一个WebMvcConfigurer，注册一个HandlerInterceptor，对所有需要登录才能访问的接口做拦截校验。把需要放行的路径（比如登录接口、注册接口、商品查询接口）做成白名单配置，其余一律先校验token再放行。

注意：JWT的SECRET_KEY不要硬编码在代码里，放到application.yml的配置项里，答辩的时候能解释出“配置与代码分离”这个意识，印象分会好很多。

2.3 商品发布与图片上传：从OSS到本地存储的两套方案

商品模块是这个平台最核心的内容。发布商品的流程是：前端填表单（标题、描述、价格、分类、成色等）加上图片文件，通过multipart/form-data方式提交到后端。这里有两个关键点需要处理：一是图片上传，二是商品状态机的初始设定。

图片上传我提供两条路。

方案一，如果愿意折腾云服务，就用阿里云OSS。申请一个Bucket，设置好跨域规则和读写权限，后端引入aliyun-sdk-oss依赖，通过上传凭证把文件传到OSS，返回URL存到数据库。这套方案的优点是不用担心磁盘空间、不用管静态资源映射，生产环境表现也好。

方案二，本地存储。在后端配置一个虚拟路径映射：

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

上传文件时保存到本地upload目录，返回给前端的图片URL就是 http://localhost:8080/upload/xxx.jpg 这样。毕业设计用这套方案完全够，不用花钱不用备案。

商品的新增，我强烈建议默认状态是“待审核”。虽然做一个小型校园平台不一定真的有管理员审核流程，但从业务规则上说，先审核后上架是正规电商平台的标配逻辑，也便于你在写论文时论述系统的“规范性”。商品状态可以用int数值存储，0待审核、1在售、2已下架、3已售出、4违规下架，这样状态扩展性也更好。

2.4 订单状态的流转：交易是系统的核心骨架

订单模块我觉得是整份代码里最值得好好设计、也最能体现技术功力的地方。一个二手交易平台不像普通电商那样有购物车、库存扣减这种逻辑（当然如果你要把购物车也加上也可以，但对我来说那会淡化“闲置交易”这个主题本身的特色），它的核心是交易双方围绕一件商品完成一次状态转移。简化来说就是这几个状态：

• 待付款：买家提交订单后、完成支付前。
• 已付款（待发货）：买家付款，卖家可以看到这个订单，准备联系买家交易或发货。
• 已发货：卖家点击发货（或线下完成交易后确认），等待买家确认。
• 已完成：买家确认收货，订单关闭，交易闭环。
• 已取消：买家未付款时取消，或者超时未付款系统自动取消。

订单状态流转在代码里怎么做得优雅一些？我建议不要在service里到处散落状态判断，而是用“if判断+常量类”就足够，但必须保证状态变更都有对应的前置校验，比如：

• 只有“待付款”状态才能取消；
• 只有“待付款”状态才能支付；
• 只有“已付款”状态卖家才能发货；
• 只有“已发货”状态买家才能确认收货。

这其实就是简化版的状态机思路。在答辩的时候，如果能画一张订单状态图（这个用普通插图就行，别用mermaid），然后讲到“每个状态变更都有前置校验，避免非法操作”，这就是一个很好的加分点。

还要考虑并发问题。二手商品最怕的是“同一件商品被两个买家同时下单”，这种问题在高并发平台要靠数据库锁或者乐观锁来做，限于毕设规模一般不会真的发生，但你在设计上可以提前规避：在提交订单的Service方法上加一个事务，并且对商品表做乐观锁处理，update的时候加一个 version 字段，只有版本号匹配才更新成功，否则提示“商品状态已变化，请刷新后重试”。这段逻辑虽小，但技术含量在这类项目里非常突出，面试也常问。

3. 实操过程与核心环节实现

3.1 项目初始化：一步步搭好SpringBoot骨架

首先去Spring Initializr（https://start.spring.io/）生成一个初始项目。但需要注意，如果你选择用SpringBoot 2.7.x，建议在这个网站页面上切换一下Spring Boot版本，默认可能已经是3.x甚至更高了，选版本的时候往下拉选2.7.18（如果界面还有的话；没有的话可以网站左侧切换为老版本服务），或者直接用IDEA内置的Spring Initializr创建。

依赖方面，基础版本勾选这几个就够了：

• Spring Web（提供Web MVC能力）
• MySQL Driver（数据库驱动）
• Lombok（简化实体类代码）
• Validation（参数校验）

Spring Data JPA先不要勾，我们是用MyBatis-Plus的，后边手动引入依赖即可。

然后在pom.xml里手动补上MyBatis-Plus Starter、JWT、FastJSON或Jackson、Hutool（可选，工具类集合）这几个依赖。MyBatis-Plus的starter是这个：

xml复制<dependency>
    <groupId>com.baomidou</groupId>
    <artifactId>mybatis-plus-boot-starter</artifactId>
    <version>3.5.3.1</version>
</dependency>

配置好application.yml，核心配置如下：

yaml复制server:
  port: 8080

spring:
  datasource:
    url: jdbc:mysql://localhost:3306/xianyipin?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai
    username: root
    password: 你的密码
    driver-class-name: com.mysql.cj.jdbc.Driver
  jackson:
    date-format: yyyy-MM-dd HH:mm:ss
    time-zone: GMT+8

mybatis-plus:
  configuration:
    log-impl: org.apache.ibatis.logging.stdout.StdOutImpl
  global-config:
    db-config:
      logic-delete-field: deleted
      logic-delete-value: 1
      logic-not-delete-value: 0

如果你接入了Redis，在pom里引入spring-boot-starter-data-redis，配置文件中增加Redis连接信息。Redis在这个系统里的典型用途是：存储验证码、维护token黑名单（用户退出登录时把token标记失效）、缓存首页热门商品和轮播图数据。把Redis用起来这个亮点，建议务必保留。

3.2 表结构落地：以商品表和订单表为例

有了表设计之后，直接用Navicat或MySQL命令行执行建表语句。我还是得提醒一句：字段名和类型在创建之初就确定好，后面不要频繁改表。毕设阶段DDL一遍过了就过了，改表带来的连锁改动极其痛苦。

商品表的建表SQL（精简版）：

sql复制CREATE TABLE `product` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `seller_id` bigint(20) NOT NULL COMMENT '卖家ID',
  `category_id` bigint(20) DEFAULT NULL COMMENT '分类ID',
  `title` varchar(100) NOT NULL COMMENT '商品标题',
  `description` text COMMENT '商品描述',
  `price` decimal(10,2) NOT NULL COMMENT '价格',
  `original_price` decimal(10,2) DEFAULT NULL COMMENT '原价',
  `cover_image` varchar(255) DEFAULT NULL COMMENT '封面图URL',
  `images` text COMMENT '多图，逗号分隔',
  `condition_level` tinyint(4) DEFAULT NULL COMMENT '成色：1全新 2几乎全新 3轻微使用痕迹 4明显使用痕迹',
  `location` varchar(100) DEFAULT NULL COMMENT '所在位置',
  `status` tinyint(4) NOT NULL DEFAULT '0' COMMENT '0待审核 1在售 2已下架 3已售出 4管理员下架',
  `view_count` int(11) DEFAULT '0' COMMENT '浏览量',
  `deleted` tinyint(4) DEFAULT '0' COMMENT '逻辑删除',
  `create_time` datetime DEFAULT NULL,
  `update_time` datetime DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `idx_seller_id` (`seller_id`),
  KEY `idx_status` (`status`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='商品表';

订单表的核心字段：

sql复制CREATE TABLE `orders` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `order_no` varchar(32) NOT NULL COMMENT '订单编号',
  `product_id` bigint(20) NOT NULL COMMENT '商品ID',
  `buyer_id` bigint(20) NOT NULL COMMENT '买家ID',
  `seller_id` bigint(20) NOT NULL COMMENT '卖家ID',
  `amount` decimal(10,2) NOT NULL COMMENT '成交金额',
  `status` tinyint(4) NOT NULL DEFAULT '0' COMMENT '0待付款 1已付款/待发货 2已发货 3已完成 4已取消',
  `message` varchar(255) DEFAULT NULL COMMENT '买家留言',
  `create_time` datetime DEFAULT NULL,
  `pay_time` datetime DEFAULT NULL,
  `complete_time` datetime DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_order_no` (`order_no`),
  KEY `idx_buyer` (`buyer_id`),
  KEY `idx_seller` (`seller_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='订单表';

为什么订单号要单独用一个字段而不是直接用自增ID？因为自增ID会暴露平台的订单量，而且如果后面做分库分表（虽然毕设不会遇到），自增ID会冲突，所以一个全局唯一的订单号是标配。生成方式可以用时间戳+随机数：

java复制String orderNo = System.currentTimeMillis() + "" + (100000 + new Random().nextInt(900000));

3.3 后端核心接口实现：商品分页查询与订单提交流程

商品的首页和搜索页，本质是同一个接口：分页条件查询。MyBatis-Plus的分页插件配置一下，然后写一个超级清爽的Service方法：

java复制public IPage<ProductVO> queryProductPage(int pageNum, int pageSize, String keyword, Long categoryId) {
    Page<Product> page = new Page<>(pageNum, pageSize);
    LambdaQueryWrapper<Product> wrapper = new LambdaQueryWrapper<>();
    wrapper.eq(Product::getStatus, 1) // 只在售
           .eq(categoryId != null, Product::getCategoryId, categoryId)
           .like(StringUtils.hasText(keyword), Product::getTitle, keyword)
           .orderByDesc(Product::getCreateTime);
    IPage<Product> productPage = productMapper.selectPage(page, wrapper);
    // 转为VO，补充卖家昵称、分类名称等展示信息
    return convertToVO(productPage);
}

这里有一个实际开发里常见的点：数据库里存的是关联ID，但前端页面要展示的是名称。比如商品表存了分类ID和卖家ID，但列表页需要展示分类名字和卖家昵称。处理方式有几种：用SQL联表查询，或者查出分页结果后批量填充。在小数据量场景下，我通常是把分页结果遍历一遍，根据ID批量查关联信息，再组装成VO返回。这样代码逻辑清晰，性能也不算差。

订单提交流程是另一个核心接口。它的核心逻辑如下：

java复制@Transactional(rollbackFor = Exception.class)
public Long createOrder(OrderCreateDTO dto, Long buyerId) {
    // 1. 校验商品存在且在售
    Product product = productMapper.selectById(dto.getProductId());
    if (product == null || product.getStatus() != 1) {
        throw new BusinessException("商品不存在或已下架");
    }
    // 2. 卖家不能买自己的商品
    if (product.getSellerId().equals(buyerId)) {
        throw new BusinessException("不能购买自己发布的商品");
    }
    // 3. 写入订单
    Orders order = new Orders();
    order.setOrderNo(generateOrderNo());
    order.setProductId(product.getId());
    order.setBuyerId(buyerId);
    order.setSellerId(product.getSellerId());
    order.setAmount(product.getPrice());
    order.setStatus(0); // 待付款
    order.setMessage(dto.getMessage());
    ordersMapper.insert(order);
    // 4. 商品状态改成“已被下单”，防止别人重复下单
    // 乐观锁：update product set status=2 where id=? and status=1
    int rows = productMapper.updateStatusWithLock(product.getId(), 1, 2);
    if (rows == 0) {
        throw new BusinessException("手慢了，商品刚刚被拍下");
    }
    return order.getId();
}

注意第4步这里就是一个经典的并发控制点。直接用状态字段做条件更新，天然避免了两单重复。这个写法在面试里很有加分效果。

支付这块，真实的支付网关（支付宝/微信支付）需要商户资质，毕设阶段不现实，一般用“模拟支付”代替：点击支付按钮，前端调后端接口，后端直接把订单状态从0改成1，同时给卖家生成一条站内消息“您的商品已有人拍下”。为了更有仪式感，可以在支付接口里加一行sleep(2000)，模拟支付耗时。这个点虽然小，但答辩时能被问到的概率很高，要能自圆其说：“当前项目因为未接入真实支付网关，所以采用模拟支付来驱动订单流程闭环”。

3.4 前端关键页面：从登录到发布商品的完整链路

前端我建议用现成的Vue后台模板来做基础，很多人不知道在哪里找，GitHub上搜“vue-admin-template”或者“mall-admin-web”之类的关键词都能找到合适的起点。但需要注意的是，模板里的权限逻辑、菜单配置、API封装可能和你自己的后端不匹配，需要按自己的接口去改。

用户端页面大概需要这些：

• 首页（搜索框+轮播图+分类导航+最新商品列表）
• 商品列表页（支持关键词、分类、价格区间筛选）
• 商品详情页（图片轮播、商品信息、卖家卡片、底部操作栏“立即购买”“加入收藏”“留言咨询”）
• 发布商品页（表单+图片上传组件）
• 订单列表页（买家视角和卖家视角的tab切换）
• 个人中心页（我的发布、我的收藏、消息通知）

前端和后端的交互统一走Axios，在main.js里全局配置请求拦截器和响应拦截器。请求拦截器里每次从localStorage取token并放进请求头：

javascript复制axios.interceptors.request.use(config => {
  const token = localStorage.getItem('token')
  if (token) {
    config.headers['Authorization'] = token
  }
  return config
})

响应拦截器里统一处理错误码，比如token过期时跳回登录页：

javascript复制axios.interceptors.response.use(
  response => response.data,
  error => {
    if (error.response && error.response.status === 401) {
      localStorage.removeItem('token')
      router.push('/login')
    }
    return Promise.reject(error)
  }
)

这些代码看着很基础，但就是这些细节，决定着项目是不是真的“能跑”。我见到不少同学代码能跑，但是token过期、接口异常的时候前台直接白屏，这就是因为响应拦截没写好。

3.5 部署上线：从本地到服务器的完整流程

毕设最后通常需要做一个可演示的版本，甚至部署到云服务器上让老师在线访问，这一步的坑也不少。

后端部署Idea里打包成jar包，这一步特别常见的问题是：明明本地运行正常，打包后一运行报错“找不到主类”或“无法加载主清单属性”。多半是pom.xml缺了spring-boot-maven-plugin，加上就好：

xml复制<build>
    <plugins>
        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
        </plugin>
    </plugins>
</build>

前端构建是 npm run build，产出dist目录。里面的静态文件可以扔到Nginx里，同时Nginx配置反向代理，解决前端跨域问题：

nginx复制server {
    listen 80;
    server_name your.domain.com;

    location / {
        root /usr/share/nginx/html;
        index index.html;
    }

    location /api/ {
        proxy_pass http://127.0.0.1:8080/;
    }
}

数据库方面，把本地的SQL文件倒入云服务器的MySQL，改一下后端配置文件里的数据库地址即可。但有个老生常谈的问题：云服务器安全组要放行对应的端口（3306、8080，甚至Nginx的80端口），否则外部访问不了，很多人第一部署失败都是因为这个。

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

4.1 端口被占用、依赖冲突、前端跨域这些高频小毛病

做这个项目的过程里，我收集了学生踩坑频率最高的若干问题，整理成一个速查表：

这些都不是什么棘手问题，但在毕设冲刺季，几乎每个人都会至少遇到其中一两个。我的建议是遇到报错先别慌，把错误日志从头读到尾，八成在前面几行就能定位到原因。不要一报错就去问AI或者搜“为什么报错”，那只会让你越来越依赖别人，自己排查一次，后面遇到同类问题就能举一反三了。

4.2 验证码登录：Redis过期策略引发的诡异问题

我做这个项目时遇到一个比较隐蔽的bug：用户请求邮箱/手机验证码登录，前端填验证码后点登录，经常提示“验证码已过期”，偶尔又能成功。排查半天发现，Redis中验证码的过期时间设的是5分钟，但每次用户请求验证码时，我没有先删除旧key再设置新key，导致验证码key在被重新赋值时，Redis的过期时间被覆盖为-1，也就是永不过期。那正常看起来应该是这样的逻辑：

java复制stringRedisTemplate.opsForValue().set(KEY, code, 5, TimeUnit.MINUTES);

但实际代码里有人写成先调了delete，又调了set，中间某个环节没生效，或者用了append导致value不对。这个问题的教训是：Redis操作不要自己脑补“差不多”的API语义，该set就set，该过期就过期，先确认官方方法行为。

4.3 商品列表展示像数独：多表关联查询的N+1问题

一个我很想强调的实际问题是：不少同学在写商品列表的时候，喜欢在循环里逐条调数据库查询卖家昵称和分类名。数据量小的时候感觉不到问题，一旦商品到了几十条，页面加载明显变慢，在答辩现场打开页面转圈圈，观感极差。

解决思路有两个方向。一是用MP的selectBatchIds批量查出所有关联用户和分类，然后本地做一次Map映射。逻辑大概是：

java复制Set<Long> sellerIds = productList.stream().map(Product::getSellerId).collect(Collectors.toSet());
List<User> users = userMapper.selectBatchIds(sellerIds);
Map<Long, String> userMap = users.stream()
        .collect(Collectors.toMap(User::getId, User::getNickname));

另一个思路是直接在SQL层面用联表查询，一次查出所有数据。MyBatis-Plus里写自定义SQL并不难，在Mapper接口上加一个方法，写好@Select注解或XML里的联表语句。但全用联表会让代码可读性下降，而且你需要特别注意列名冲突的问题，所以我个人更推荐第一种方式，代码清爽且容易理解。

4.4 图片上传与预览：getRealPath的坑和跨域访问

图片上传这个环节，很多人会踩到一个经典大坑：在本地开发时用request.getServletContext().getRealPath("/upload")能得到正确的绝对路径，但部署到服务器上后，才发现这个路径可能因为运行方式不同而变得不可控。或者服务器上Tomcat的配置不同，路径解析出来是临时目录，重启就丢了。

为了避免这个不确定性，我强烈建议：在application.yml里通过配置项指定图片保存目录，而不是依赖servlet容器的解析：

yaml复制upload:
  dir: /data/upload/    # 服务器上的路径
  # dir: D:/upload/     # Windows本地路径

后端代码读取配置并做映射：

java复制@Value("${upload.dir}")
private String uploadDir;

@Override
public void addResourceHandlers(ResourceHandlerRegistry registry) {
    registry.addResourceHandler("/upload/**")
            .addResourceHandler("file:" + uploadDir);
}

这样一来，本地开发、服务器部署的行为完全可控，图片不会莫名消失。另外一个细节是跨域问题：如果你的图片URL是http://localhost:8080/upload/xxx.jpg，而前端部署在另一个端口，那就要确保后端已经配置了CORS策略，否则图片虽然存在，但浏览器会因为跨域而加载不出来。

4.5 交易闭环测试：如何快速验证订单流程不出错

功能开发完之后，千万不要直接打包交差，一定要把核心链路完整走一遍。我建议按下面的清单跑一遍自己的系统：

• 注册两个账号（一个买家、一个卖家）
• 卖家登录，发布一件商品，上传图片，确认状态是待审核
• 管理员登录，审核通过
• 退出登录，切换买家账号，搜索到该商品，点击购买
• 确认订单信息，提交订单，看到订单状态是待付款
• 点击模拟支付，此时卖家收到“你有新订单”的站内信
• 切换卖家账号，对订单进行发货
• 切换买家账号，确认收货，订单变更为已完成
• 查看商品状态，已变成已售出/下架状态
• 买家到个人中心，对商品进行评价（如果有该模块）

走完这条链路，系统是否可用基本就心里有数了。如果中间任何一步卡住，立刻回到代码里打日志排查，往往不难发现是状态判断条件写错、或者是某个接口的前置校验没通过。这个自测的过程，也正好是理解系统业务流程的最佳机会。

5. 一点经验之谈和可以继续扩展的方向

5.1 我给做毕设同学的三条实用建议

这个项目我前前后后带过很多学生走完过，有些话我觉得还是值得多啰嗦一遍。

第一条，代码可以抄，但思路和行为别抄。网上确实有大把的同类开源项目，直接clone下来换个皮就能当毕设交——但答辩的时候，老师问一句“这个订单状态怎么流转的？”答不上来，场面会非常尴尬。更好的做法是：认真读别人的代码，理解它的表结构和业务流程，然后自己动手重写一遍或大改一遍，让它变成你真正熟悉的东西。写作过程中不要只追求“能跑”，每一步都要知道自己在做什么。

第二条，文档和代码同步走。很多同学习惯最后两周才开始写论文，结果发现代码里的某些设计细节已经记不清了。我的建议是：每做完一个模块，顺手用一两段话记录一下这个模块的需求、实现方式、技术要点。到写论文的时候，这些碎片直接就是核心章节的素材，效率翻倍。

第三条，保留一个自己的技术亮点。全系统如果都只是CRUD，答辩确实单薄。但你可以刻意在某一个点上加一点深度——比如订单提交时的乐观锁防超卖、图片列表的分片上传、或者用Redis缓存首页数据减少数据库压力。哪怕只是在代码里实现了，文档里重点写、答辩时重点讲，这就足以让你的项目从“及格”上升到“良好”。

5.2 从毕设到简历：这个项目可以延伸出的技术点

做完这个系统之后，有几条技术深化的路线如果你感兴趣，后续可以自己折腾：

一是引入RabbitMQ做订单超时取消。具体做法是：用户下单后发一条延迟消息，30分钟未支付就自动把订单状态改成已取消，把商品状态改回在售。这个方案在真实电商场景里非常经典，面试题里的“订单有效期”考的就是这个。

二是把支付模块对接真实沙箱环境。支付宝有沙箱环境，注册开发者账号之后可以拿到测试用的AppID和密钥，对接起来并不难。能真实支付转账的毕设系统，在答辩中的说服力会明显高一个档次。

三是做一个简单的推荐位或“猜你喜欢”模块。不看复杂的协同过滤，单纯按分类偏好、浏览记录来推荐相关商品，也能让系统看起来更智能一些，而且数据量小，实现成本不高。

这些方向不需要在毕设阶段全部做完，但如果你做完主系统还有富余时间，挑一个做进去，简历和论文都会更丰富。而如果你不打算继续扩展，那把这个系统吃透、把核心流程能讲明白，对求职面试的Java后端岗位也已经是很好的项目经历了。

最后分享一个实操中的小技巧：开发过程中养成随手写接口文档的习惯。不用搞复杂的Swagger配置，只需要在Controller上写清楚每个接口的用途和参数，再用Postman或者Apifox保存一套完整的请求示例。这样不仅自己调试方便，最后写论文的“系统实现”章节时也能直接照着整理成表格，省下大量回忆和复测的时间。