简介基于SpringBoot框架的二手物品交易系统毕业设计项目面向计算机相关专业正在准备毕设的学生也适合需要项目实战经验的Java学习者还可用于课程设计或期末大作业。系统采用SpringBoot后台框架与MySQL数据库基于JDK和IDEA开发完整覆盖二手交易场景的核心业务逻辑。压缩包共633个文件大小约18.27MB内部以Java源码、FreeMarker模板、JavaScript、CSS及图片资源为主并包含数据库脚本、项目配置与说明文档其中Java与FreeMarker文件支撑后端业务JS、CSS、图片等构成前端界面SQL脚本负责初始化数据整体目录结构清晰便于定位与学习。项目经过严格调试确保可直接运行附带的配置方法和说明文档能帮助快速搭建环境。已有293人学习/下载适合作为毕业设计基础版本或SpringBoot前后端开发的实操参考也便于在此基础上进行二次扩展。1. 为什么“基于Spring Boot的二手物品交易系统”是Java毕业设计里最稳妥的项目如果你现在正打开某个资源站看到“java毕业设计-基于springboot的二手物品交易系统项目源码数据库.zip”这个标题说明你已经走到一个很具体的节点要么是准备答辩要么是刚开始做毕设不知道从哪里下手要么是想找一个结构完整的Spring Boot项目用来刷熟框架。这三种诉求实际上指向同一个东西——你需要的不是一个“能跑的代码包”而是一个能讲明白、能改、能回答老师追问的完整业务系统。二手交易系统恰好卡在这个位置上业务足够日常商品发布、商品浏览、下单、订单管理技术栈足够典型Spring Boot MyBatis MySQL模块划分足够清晰而且它天然有交易流程能支撑起“状态流转”“事务控制”“权限校验”这类答辩高频问题。这也是为什么它在毕业设计领域几乎是常青树。但这里有一个很现实的问题你下载到的压缩包只是一个起点。真正决定你能不能顺利答辩的是你是否理解这个系统怎么拆、数据库怎么设计的、核心接口在做什么。本文就按一个一线Java开发者的视角把这个项目从解压到跑通、从看代码到能改代码的完整路径写清楚包含目录结构怎么读、关键代码怎么改、数据库脚本怎么落、部署时哪些坑必须避免以及如果想让它从“能跑”变成“像个产品”还需要动什么。内容全部围绕这个基于Spring Boot的二手物品交易系统展开不扯远只讲你打开压缩包后会遇到的事。2. 先把这个Spring Boot项目拆开看模块边界、核心对象与最小启动配置2.1 从模块边界理解二手交易系统的三个核心域解压压缩包后你会看到的典型Spring Boot工程结构大概是这样的不同作者习惯略有差别但大同小异src/main/java/com/example/secondhand ├── controller ├── service │ └── impl ├── mapper ├── entity ├── config └── SecondhandApplication.java src/main/resources ├── mapper ├── static ├── templates └── application.yml先不要急着点开代码你要先建立一个认知框架。二手物品交易系统的业务核心域只有三个用户user、商品product、订单order。这三个域之间的关系是用户发布商品用户浏览商品用户下单购买商品卖家确认交易订单状态不断变化。很多初学者拿到项目后迷茫是因为把所有注意力放在单个页面上而不是放在这三个核心域的数据流转上。我一般建议拿到源码后第一步不是看代码而是画一张数据流图用户登录后能做什么、商品从发布到下架走什么状态、订单从创建到完成有哪些节点。这张图画清楚你后面看代码会非常快。这个系统的技术选型在毕业设计中几乎是标准答案Spring Boot负责接口和业务代码MyBatis负责数据库访问数据库用MySQL页面端用Thymeleaf模板引擎或者前后端分离的Vue。你拿到的项目中如果是前后端不分离的Thymeleaf版本那么static和templates目录就存在如果是前后端分离版本那么src/main/resources下可能只有application.yml前端代码放在独立目录。不管哪种后端接口的职责是相同的本文后面讲代码时也以接口为核心讲。2.2 两个必须读懂的配置文件pom.xml和application.yml打开项目后第一件事是看pom.xml。这个文件定义了你的项目依赖版本毕业设计项目最常见的翻车现场就在这里——Spring Boot父版本和Java版本不匹配。例如Spring Boot 2.x要求Java 8或者11Spring Boot 3.x要求Java 17。如果你的本机是Java 8却下载了一个Spring Boot 3.x的项目那启动就会直接报错。这里给出一段典型pom.xml的核心依赖供你对照parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version2.5.4/version relativePath/ /parent dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.mybatis.spring.boot/groupId artifactIdmybatis-spring-boot-starter/artifactId version2.2.0/version /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scoperuntime/scope /dependency dependency groupIdorg.projectlombok/groupId artifactIdlombok/artifactId optionaltrue/optional /dependency /dependencies这个配置里有两个关键点。第一spring-boot-starter-parent的版本决定了你整个项目的技术基线比如Spring Boot 2.5.x自动装配的是Spring 5.x默认支持Servlet容器是Tomcat 9这些不用你管但你不能随意改动这个版本否则各种starter之间的兼容性会一起连锁翻车。第二mybatis-spring-boot-starter的版本由项目自己指定release版本需要和Spring Boot版本兼容2.2.0这个版本对2.5.x是稳妥的组合如果你改成3.x的MyBatis starter代码里的一些配置可能就要变。Java和Spring Boot的版本坑几乎是这个标题下最高频的问题后面避坑章节会专门讲。再看application.yml这是Spring Boot项目的数据源和核心配置我一般拿到项目会先把注释读完再改。这里给出一段典型的配置样式server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/secondhand?useUnicodetruecharacterEncodingutf-8useSSLfalseserverTimezoneAsia/Shanghai username: root password: root servlet: multipart: max-file-size: 10MB max-request-size: 10MB mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.example.secondhand.entity configuration: map-underscore-to-camel-case: true这里最需要你手动改的就是url、username、password。url里的secondhand是数据库名你需要提前在MySQL里创建同名数据库再导入压缩包里的sql文件。serverTimezoneAsia/Shanghai这个参数在MySQL 8.x下必须保留否则数据库连接会报时区错误。map-underscore-to-camel-case: true是有意思的一点它让数据库字段的user_name自动映射成Java实体类的userName在写MyBatis代码时不需要手动做下划线转驼峰。这个小配置能帮你省大量时间但前提是你的数据库字段名和下划线命名保持规范。2.3 启动项目的最小路径导入SQL、改配置、启动主类拿到项目后正确顺序是“先看SQL再改配置最后启动主类”而不是直接双击运行。压缩包里的数据库脚本通常是一个.sql文件你要在Navicat或者命令行里先创建数据库再导入这个脚本。注意如果脚本里有CREATE DATABASE语句你就只需要执行脚本如果没有你就要手动建库。很多项目脚本里不带建库语句只写了USE语句导致新手导入后提示选择数据库。导入SQL后修改application.yml里的账号密码然后在SecondhandApplication.java上右键运行。这个主类看起来非常简单package com.example.secondhand; import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; SpringBootApplication public class SecondhandApplication { public static void main(String[] args) { SpringApplication.run(SecondhandApplication.class, args); } }SpringBootApplication这个注解背后是组件扫描和自动配置的组合。它会默认扫描当前包以及子包下的所有被Component、Service、Controller标注的类所以如果你把新建的类放到了com.example.secondhand包外面它就不会被扫描到接口会404。这是初学者最常遇到的黑匣子之一。启动成功后控制台会出现Tomcat started on port(s): 8080然后在浏览器访问localhost:8080就能看到系统的登录页。如果只是到这里你只是完成了第一步——跑通后面要做的才是真正值钱的事。3. 从商品发布到订单成交核心业务接口的代码路径与参数设计3.1 商品发布接口参数校验与图片上传的处理逻辑二手交易系统的第一个核心操作是“卖家发布商品”。这个操作在代码里的落点是ProductController里的一个POST接口。我建议你拿到项目后先找到这个接口并完整读一遍它的参数传递路径。常见写法大概是这样RestController RequestMapping(/api/product) public class ProductController { Autowired private ProductService productService; PostMapping(/publish) public Result publish(RequestParam(title) String title, RequestParam(description) String description, RequestParam(price) BigDecimal price, RequestParam(categoryId) Integer categoryId, RequestParam(value image, required false) MultipartFile image, HttpSession session) { User user (User) session.getAttribute(user); if (user null) { return Result.error(401, 请先登录); } String imagePath null; if (image ! null !image.isEmpty()) { imagePath fileService.upload(image); } Product product new Product(); product.setTitle(title); product.setDescription(description); product.setPrice(price); product.setCategoryId(categoryId); product.setImagePath(imagePath); product.setSellerId(user.getId()); product.setStatus(0); productService.addProduct(product); return Result.success(); } }这段代码里的参数传递方式值得展开。RequestParam接收的是form表单字段这是和前端配合时的约定如果用JSON传参就改成RequestBody。price用BigDecimal而不是Double这是交易系统里必须遵守的纪律因为Double的精度问题会在金额计算上造成莫名其妙的误差。商品的初始状态设置为0意思是“上架中”这个状态位的约定会在订单逻辑里反复用到。MultipartFile的requiredfalse表示图片是可选的如果前端传了文件就上传保存没传也能发布。这里还有一个典型的细节从session里取用户对象。在学生项目中用HttpSession保存登录态是很常见的做法但它的坑在于如果服务端是集群部署或者前后端分离跨域session就不好使了这在最后一章会讲怎么升级。商品发布流程里图片上传这个环节很多项目的实现在工程上是有问题的。最常见的做法是把图片保存到本地磁盘路径然后通过一个映射把磁盘路径暴露成URL访问。比如这样Value(${file.upload-path}) private String uploadPath; public String upload(MultipartFile file) { String originalFilename file.getOriginalFilename(); String suffix originalFilename.substring(originalFilename.lastIndexOf(.)); String filename UUID.randomUUID() suffix; File dest new File(uploadPath filename); try { file.transferTo(dest); return /files/ filename; } catch (IOException e) { throw new BusinessException(文件上传失败); } }文件名用UUID重命名是必须的因为用户上传的原始文件名可能是中文或者含特殊字符直接保存会有路径问题。uploadPath这个配置项应该在application.yml里定义指向一个本机目录。这个做法在毕业设计里完全够用但它有一个隐患项目换一台电脑运行上传目录不存在或路径不对图片就404了而且这个目录一旦重新打包部署里面的图片不会跟着JAR包走数据就会“丢”。后面避坑章节会专门讲这个问题的处理。3.2 商品搜索与列表分页参数和动态SQL的配合浏览商品列表是买家侧的核心入口也是面试官喜欢问“MyBatis动态SQL”的地方。一般项目中会有一个ProductMapper.xml里面的查询语句会支持按标题关键词搜索、按分类筛选、按价格排序、分页。来看一段典型的动态SQLselect idsearchProducts resultTypecom.example.secondhand.entity.Product SELECT * FROM product where if testkeyword ! null and keyword ! AND title LIKE CONCAT(%, #{keyword}, %) /if if testcategoryId ! null AND category_id #{categoryId} /if if teststatus ! null AND status #{status} /if /where if testsort price_asc ORDER BY price ASC /if if testsort price_desc ORDER BY price DESC /if if testsort time ORDER BY create_time DESC /if LIMIT #{offset}, #{pageSize} /selectwhere标签是MyBatis里很聪明的设计它会自动去掉第一个条件前面的AND避免你写11那种很丑的空条件匹配。offset和pageSize是分页参数由传入的页码和每页条数计算得出。这里要注意一个容易写错的地方LIKE后面的CONCAT函数在MySQL里是这么写的如果是在Oracle数据库里就要改成||拼接项目要换数据库的话这地方就得动。搜索关键字的处理如果用户传入%或者是_这种SQL通配符会有SQL注入风险正规一点的项目会用MyBatis的bind标签或者直接在代码层把特殊字符转义掉。不过毕业设计里直接拼接是最常见的写法你要知道它的短板在哪儿就行。3.3 下单接口事务与库存状态的关键逻辑交易系统的重头戏是“买家下单”这个动作。它的业务要点是商品不能被重复买、买家不能买自己的商品、订单生成后卖家和买家都要能看到。后端的实现一般放在OrderController和OrderService里核心代码长这样Transactional(rollbackFor Exception.class) public Order createOrder(Integer productId, Integer buyerId, Integer quantity) { Product product productMapper.selectById(productId); if (product null) { throw new BusinessException(商品不存在); } if (product.getStatus() ! 0) { throw new BusinessException(商品已下架或已被购买); } if (product.getSellerId().equals(buyerId)) { throw new BusinessException(不能购买自己发布的商品); } // 扣减库存二手交易一般为1件但保留数量字段 int updateCount productMapper.deductStock(productId); if (updateCount 0) { throw new BusinessException(库存不足或商品状态已变化); } Order order new Order(); order.setProductId(productId); order.setBuyerId(buyerId); order.setSellerId(product.getSellerId()); order.setTotalPrice(product.getPrice()); order.setStatus(0); orderMapper.insert(order); // 更新商品状态为已出售 productMapper.updateStatus(productId, 2); return order; }注意这里的Transactional(rollbackFor Exception.class)注解。它保证这个方法里任意一步抛出异常前面已经执行的数据库操作全部回滚。很多新手项目会漏掉rollbackFor Exception.class这个参数导致Service抛出业务异常后数据库不配合回滚这是一个非常隐蔽的翻车现场后面会单独讲。deductStock这个方法做的事是UPDATE product SET stock stock - 1 WHERE id #{id} AND stock 0这个写法用数据库行锁天然解决并发下的超卖问题比先select再update再判断的方式靠谱得多。下单后把商品状态改成2意味着“已出售”这个状态和发布的0上架对应商品从列表里消失避免别人继续下单。这套逻辑在二手交易场景下是合理的——一件商品只能卖给一个人。下单接口做完后你可以写一个简单的JUnit测试来验证事务是否真的生效比如故意传一个不存在的productId看订单表里有没有留下脏数据。这个验证方法能帮你确认项目的事务配置是不是好的。4. 数据库设计是这套源码的骨架核心表结构、初始数据与事务配置4.1 核心表的字段设计与代码中的对应关系打开压缩包里的.sql文件你会看到这个系统背后实际的数据库长什么样。二手物品交易系统的数据库设计不会太复杂但有一个特点表之间的外键关系、状态字段、时间字段都做得比较齐全这说明作者是按“可讲解”的标准来设计的。核心表一般在5到8张之间我挑最核心的来说明。用户表、商品表、订单表是必有的。用户表的字段一般是id、username、password、nickname、phone、avatar、create_time。password字段千万注意不能是明文多数项目会用MD5加密存储也就是注册时把密码用MD5加密后再插入这个细节在答辩时经常被问到。商品表的字段是id、seller_id、category_id、title、description、price、image_path、status、stock、create_time。这里的status字段含义有约定0表示上架中1表示已下架2表示已出售。这个状态位的可解释性很强答辩时你可以顺带讲出“为什么下架和已出售要分开而不是用一个状态”。订单表是id、order_no、product_id、buyer_id、seller_id、total_price、status、create_time。order_no是订单编号通常会用时间戳加随机数生成。这里建议你关注一个设计订单表里同时存了buyer_id和seller_id这个设计是故意的因为列表页要分别展示“我买到的”和“我卖出的”这两个视图只要按对应字段查一次就能出来不用再做关联。这个设计思路在答辩时可以展开讲。除了这三张核心表通常还有分类表category字段是id、name、parent_id收藏表favorite字段是id、user_id、product_id、create_time。如果项目里有评价功能还会有review表。表不多但关系设计足够说明问题。你可以用Navicat打开导入后的库点击“模型”功能看表关系图这是你快速熟悉系统的最高效方式。4.2 建表语句中的三个关键点字符集、时间字段、外键看SQL建表脚本时你要重点关注三件事。第一是建表语句的默认字符集比如CREATE TABLE user ( id int(11) NOT NULL AUTO_INCREMENT, username varchar(50) NOT NULL, password varchar(64) NOT NULL, nickname varchar(50) DEFAULT NULL, phone varchar(20) DEFAULT NULL, avatar varchar(255) DEFAULT NULL, create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;engine使用InnoDB和charset使用utf8mb4这两点是你在导入SQL后检查是否成功的关键指标。InnoDB支持事务和外键MyISAM不支持utf8mb4支持emoji字符utf8不支持。如果建表脚本里写的是MyISAM或者默认utf8说明作者用的是比较老的习惯你可以改掉再导入。CREATE TABLE的字段注释建议在SQL里保留后面你用代码生成器生成实体类时会非常省事。第二是时间字段的处理逻辑。create_time用DEFAULT CURRENT_TIMESTAMPupdate_time这种如果存在的话一般用ON UPDATE CURRENT_TIMESTAMP这样在更新记录时时间字段自动刷新代码层不用手动维护。这个细节在代码评审时是加分项因为很多开发者会忘记手动更新时间字段导致数据时间不准确。第三是外键。二手交易系统的外键一般不会在物理上定义因为外键约束会影响删除性能和批量导入这张表的关联逻辑都在应用层通过JOIN查询体现。比如查询商品详情时要显示卖家昵称代码里的SQL可能是SELECT p.*, u.nickname AS seller_nickname FROM product p LEFT JOIN user u ON p.seller_id u.id WHERE p.id #{id}这是一种趁手的约定表结构干净查询时按需关联而不是数据库层面强制维护外键完整性。这种设计的取舍在答辩时可以主动讲是一个加分点。4.3 连接池与事务配置在代码里的落地数据库设计不只是建表还包括连接和事务的配置。Spring Boot项目里连接池的默认选择是HikariCP它的默认配置已经足够应对毕业设计场景你不用特别调。但Mini连接池的处理还是值得关注的——如果项目里自定义了连接池配置应该长这样spring: datasource: hikari: minimum-idle: 5 maximum-pool-size: 20 idle-timeout: 30000 connection-timeout: 30000这些参数的意思分别是最小空闲连接数、最大连接池大小、空闲超时时间、获取连接超时时间。学生项目里并发不会很高这个配置够用了。如果项目里的连接数一直居高不下你从这些参数先看起。事务配置部分Spring Boot默认已经开启声明式事务你只需要在Service实现类上使用Transactional注解就不需要额外的XML配置。唯一要留意的是事务是否真正生效避坑章节会展开讲一个常见的“事务方法内部自调用失效”的问题这是实际开发里很容易撞到的隐形陷阱。5. 部署与二次开发避坑六个高频翻车点与排查路径5.1 JDK版本和Spring Boot版本不匹配导致项目启动失败现象解压项目后用IDEA打开Maven自动下载依赖后点击启动控制台直接报一大堆关于UnsupportedClassVersionError或者AnnotationProcessingException的错误项目根本启动不了。原因这是整个压缩包场景下最常见的问题。Spring Boot 2.x基于Java 8和Java 11测试Spring Boot 3.x强制要求Java 17。你本机装的JDK版本和pom.xml中的parent版本不匹配编译运行就会直接翻车。还有一种情况是项目里引用的某些依赖要求高版本JDK而你的IDEA虽然配置了Java 17但Project Structure里Project SDK还是1.8。解决先确认本机JDK版本再对照pom.xml里的spring-boot-starter-parent版本。如果版本对应不上最省事的方案不是换JDK而是把pom.xml里的parent版本改成匹配你JDK的版本。例如你本机是JDK 8就把Spring Boot版本改成2.5.x或2.7.x如果本机是JDK 17就保持在3.x。改完版本后注意刷新Maven让依赖重新下载。这类问题别看乱本质就是一张版本兼容表Spring Boot 2.x配Java 8或11Spring Boot 3.x配Java 17。5.2 图片上传后访问404文件存到了本地磁盘却映射不到URL现象上传商品图片时没有报错后台目录里也真实生成了图片文件但在页面上访问图片URL时出现404。原因这个项目使用了本地磁盘存储方案通过一个WebMvcConfigurer的资源配置映射把本地路径暴露成URL。如果你没有正确配置映射Spring Boot默认只在classpath静态目录下找资源不会跑到你的磁盘目录里读取文件。解决找到config包下的WebConfig或者ResourceConfig类检查是否有这样一段配置Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/files/**) .addResourceLocations(file: uploadPath); }这段配置的意思是URL中以/files/开头的请求会映射到本地磁盘的uploadPath目录。注意addResourceLocations里的路径后面必须带斜杠而且前缀必须是file:。uploadPath是从application.yml里读取的你需要检查这个值是否以/结尾。如果你改了上传路径要重启项目因为Value注解是在启动时注入的。5.3 前端页面请求接口报404Controller类没被扫描到现象:项目能启动访问页面也正常但调用某个Controller接口会直接报404查看日志发现请求根本没有进入你的方法。原因Controller所在的包不在SpringBootApplication注解的扫描范围内。比如主类是com.example.secondhand.SecondhandApplication你把新建的Controller放到了com.example.controller包里SpringBoot默认只会扫描com.example.secondhand包及其子包外面的类不会被加载。解决要么把新建的Controller移到主类所在包的子包下要么在主类上添加scanBasePackages属性例如SpringBootApplication(scanBasePackages {com.example.secondhand, com.example.controller})。从规范性的角度我更推荐前者保持包结构统一免得以后越加越乱。5.4 事务不起作用的两个典型场景私有方法和类内部自调用现象Service方法里开了一个事务方法内先插入订单再抛出RuntimeException结果事务没有回滚数据还是落库了。原因第一Transactional注解加在了private方法上Spring的事务代理根本拦不住。第二事务方法在同一个类的另一个方法里被this调用比如addOrder方法内部调用了同一个类的createOrder方法createOrder上的事务注解不会被触发因为this调用绕过了代理。解决事务注解必须加在public方法上。自调用场景要注入自己的Service代理或把被调用的方法拆分到另一个Service里。最简单的解决方案是在Controller层就直接调用标注事务的Service方法不要在Service内部做链式自调。你可以在代码里搜索一下有没有这种写法this.xxxMethod()。有的话就要小心事务失效问题。5.5 数据库时区错误导致连接失败或时间错乱现象启动项目时控制台报错The server time zone value Öйú±ê׼ʱ¼ä或者写入数据库的时间与本地时间差了8小时。原因MySQL 8.x版本对时区信息更敏感JDBC连接串里没有指定serverTimezone时驱动会读取MySQL系统时区出现乱码或者偏移。另一个常见情况是MySQL的时区设置和Java应用的系统时区不一致Java使用了Asia/Shanghai而MySQL使用了UTC。解决在jdbc连接串里加上serverTimezoneAsia/Shanghai。同时确认MySQL连接串别丢了这个配置。如果已经启动过并写入了一些时间错乱的数据你可以在MySQL命令行执行SET time_zone 8:00再检查已有数据的时间是否正确。时间戳字段如果在设计时用的是datetime类型一般不需要专门改数据如果是timestamp类型再次插入时驱动会按新的时区重新计算。5.6 修改密码和用户数据后还是登录不上MD5加密方式不一致现象项目里的用户是导入SQL脚本来的用脚本里默认账号密码能登录但你在代码里新注册一个用户后再用新用户登录显示密码错误。原因注册和登录用了不同的密码加密方式。有的项目在注册时是MD5加密但登录时因为SQL写法的原因把MD5加密后的值又加密一次。还有一种情况你修改了注册代码的逻辑但登录查询MySQL的SQL语句里还是用userId查询密码比对方式不一致。解决找到登录的Service实现梳理一遍密码的校验链路。一般来说注册时对前端传来的明文密码进行加密登录时用同样的加密算法处理输入的密码然后与数据库中的密文比对。最稳妥的做法是在实体类中新增一个方法把输入的密码转成密文后与数据库里的值直接equals比较。在百度搜索“java MD5加密”会有很多示例你需要注意的是项目代码里使用了什么盐值salt如果加密时加了盐那么登录时也必须用同一个盐值重新计算。这六个坑基本覆盖了毕业设计Spring Boot项目从部署到二次开发的最常见翻车现场。很多人卡住不是因为代码复杂而是因为这些基础配置上的一两个遗漏。排查思路都是同一个套路看日志、看配置文件、看依赖版本按顺序逐一确认。6. 从能跑通到能讲清楚三个值得动手升级的关键点如果你已经到了能正常启动、能登录、能走通买卖流程的阶段那这个系统对你来说最大的价值就不是跑代码了而是把它变成答辩时能展示你能力的东西。我建议你动手做三件事每一件都不复杂但带来的提升是质的。第一件事是登录鉴权从Session换成JWT。毕业设计项目大多用HttpSession保存登录状态这在单机部署下没问题但如果你在答辩时说“我了解前后端分离”那么Session方案就成了短板。JWT的思路是服务端不再保存登录状态而是把用户信息加密放进一个token串发给前端前端每次请求都带上它。具体实现可以引入jjwt依赖在用户登录成功后生成token再写一个拦截器处理请求头里的token并解析出userId。这个改造涉及的点登录接口返回token、前端每次请求带上token头、后端拦截器校验token三个环节成闭环。改完之后你的系统在架构上就比一般毕业设计高一个级别而且面试官问起来你也有细节可讲。第二件事是搜索功能从LIKE改成全文检索思路。现在的系统如果你搜索“苹果手机”它执行的SQL是WHERE title LIKE %苹果手机%这个在数据量小的时候没问题但一旦数据变多数据库的全文索引或分词搜索就体现出明显优势。毕业设计要做到什么程度取决于你的基础——如果时间紧至少可以做到在SQL层面加一个联合索引优化查询速度给title和description字段创建索引并验证执行计划是否走索引。如果时间充裕可以引入Elasticsearch但这一步对毕业设计来说可能投入产出比不高我更推荐你把精力放在优化现有SQL的索引设计上顺便学一下EXPLAIN命令怎么看。答辩时讲出“我用EXPLAIN分析过这个查询它走了全表扫描我加了联合索引后变成索引扫描”这句话远比你引用了什么框架更能打动人。第三件事是订单超时状态的处理。现在的交易系统里如果买家下单后不付款订单一直是“待付款”状态永远不会自动取消。真实场景下一般会用定时任务扫描超过30分钟未支付的订单并自动关闭。Spring Boot里实现这个很简单启动类加上EnableScheduling新增一个定时任务类注解Scheduled(cron 0 */5 * * * ? *)每5分钟扫描一次订单表把状态为待付款且创建时间超过30分钟的订单改成已取消同时把商品状态恢复成上架。这段代码本身只有十几行但它在业务闭环上有重要意义——说明你考虑到了用户行为和异常流程的处理而不只是把CRUD跑通就完事了。做完这三件事这个二手物品交易系统就不再是那个压缩包里只保证“能跑”的模板而是成为你能独立解释每一个设计决策的作品。最后说一个我自己的习惯拿到任何一套源码不要急着改业务代码先把日志能力养好。最简单的做法是在application.yml里配置日志级别把mapper层的日志打印出来这样你每次发起查询控制台都会打印完整的SQL语句和参数值出问题时能直接定位是SQL写错还是参数传错。很多人调试Spring Boot项目想不通为什么数据不对其实就是因为没看到真实执行的SQL。你在自己的项目里加上这段配置logging: level: com.example.secondhand.mapper: debug之后控制台就会打印每条SQL的完整执行日志。配完它再跑一遍下单流程你会看到事务里到底执行了几条SQL、每一条的参数是什么这个认知对理解和排查项目都是最有用的。希望这些经验能帮你把这个基于Spring Boot的二手物品交易系统真正吃透不管是用来毕业答辩还是作为学习的跳板都能交出一份自己满意的答卷。本文还有配套的精品资源点击获取