Spring Boot校园闲置交易毕设：表结构、订单状态机与避坑指南

简介基于Spring Boot开发的校园闲置物品交易网站毕业设计项目面向Java方向毕业生、需要课程设计参考的在校生及初学Spring Boot的开发者提供从需求分析到系统测试的完整工程示范。系统围绕校园场景实现闲置商品发布、浏览检索、在线交易及后台数据管理采用前后端分离架构管理员端与用户端功能分明。资源包共785个文件压缩体积约22.63MB以java后端工程、vue与html前端视图、js交互脚本、css样式及svg图标为主要构成另包含数据库初始化sql、Maven配置、jar依赖包和论文答辩PPT。论文分六章展开绪论交代课题背景技术选型讲解Spring Boot、MySQL与Tomcat需求分析讨论可行性与系统功能系统设计给出数据库ER图与表结构系统实现展示管理员后台、前台首页与用户模块系统测试验证运行稳定性已有159人学习下载。完整源码配合章节清晰的论文可帮助读者快速定位闲置交易系统的核心实现逻辑尤其适合用于毕业设计参考、二次开发练习或答辩材料准备。1. 校园闲置物品交易网站Spring Boot毕设的“经典题”与它的三个真考点校园闲置物品交易网站这个Spring Boot毕设题目属于典型的“听起来不复杂做起来全在细节里”的项目。二手交易没有商品SKU维度、没有复杂的促销规则核心链路无非是用户发布闲置、浏览商品、发起购买、线下自提或校内当面交易。但真正让一届届学生熬夜翻车的是三个点一是订单状态怎么流转才不越界二是商品图片上传后部署时总是404三是答辩演示时打开页面发现订单数据对不上。这篇笔记会从表结构设计、后端核心代码、论文与PPT写法、常见踩坑四个方向把整套方案完整拆开照着做就能跑通。2. 业务边界与表结构设计先把订单状态机画清楚再谈代码2.1 校园场景的业务边界回收站式发布、校内自提、站内信校园闲置物品交易和闲鱼这类通用二手平台最大的区别在于交易半径极小。买卖双方大概率在同一栋宿舍楼、同一个食堂圈子里所以业务上不需要物流体系不需要第三方担保支付甚至不需要复杂的地址管理。常见做法是线下自提或者约在校内某个固定地点见面订单流程只要做到“买家表达意向→卖家确认→线下成交→双方互相评价”就够了。这意味着后端业务模型可以比想象中轻很多。如果你按淘宝的模型去设计反而会给自己挖坑——支付回调、退款流程、物流轨迹这些模块一旦开做一个月都收不了尾。做毕设题目时要把边界画清楚网站只提供信息撮合和订单意向管理不介入真实资金流转论文里的“系统实现”也围绕这个边界展开。适合这个题目的技术选型很明确Spring Boot作为后端框架负责接口和业务逻辑MyBatis-Plus操作数据库简化单表CRUDMySQL存储业务数据前端可以用JSP或者Thymeleaf配合Bootstrap也可以完全分离做成Vue页面。如果想要论文里有“技术亮点”就再加一个Redis做热点商品缓存或者用RabbitMQ做下单通知这两个点都会变成答辩加分项。2.2 核心表结构用户、商品、订单、收藏的字段设计与SQL实现表结构设计是整个项目的骨架。按最常见的需求拆分最少需要五张核心表user用户表、product闲置商品表、orders订单表、favorite收藏表、message站内信表。下面给出可以直接复用的建表脚本-- 用户表 CREATE TABLE user ( id INT NOT NULL AUTO_INCREMENT, username VARCHAR(50) NOT NULL COMMENT 登录账号, password VARCHAR(100) NOT NULL COMMENT BCrypt加密后的密码, nickname VARCHAR(50) DEFAULT NULL COMMENT 昵称默认取用户名, phone VARCHAR(20) DEFAULT NULL COMMENT 手机号, avatar VARCHAR(255) DEFAULT NULL COMMENT 头像路径, role TINYINT NOT NULL DEFAULT 0 COMMENT 0-普通用户 1-管理员, status TINYINT NOT NULL DEFAULT 1 COMMENT 1-正常 0-禁用, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_username (username) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT用户表; -- 闲置商品表 CREATE TABLE product ( id INT NOT NULL AUTO_INCREMENT, user_id INT NOT NULL COMMENT 发布者ID, title VARCHAR(100) NOT NULL COMMENT 商品标题, description TEXT COMMENT 商品描述, price DECIMAL(10,2) NOT NULL DEFAULT 0 价格单位元, original_price DECIMAL(10,2) DEFAULT NULL COMMENT 原价/入手价用于展示成色, category VARCHAR(30) DEFAULT NULL COMMENT 分类教材/数码/生活用品等, images VARCHAR(1024) DEFAULT NULL COMMENT 图片路径多张用逗号分隔, status TINYINT NOT NULL DEFAULT 0 COMMENT 0-待审核 1-上架中 2-已下架 3-已卖出, view_count INT NOT NULL DEFAULT 0 COMMENT 浏览量, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_user_id (user_id), KEY idx_status (status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT闲置商品表;两张核心表的SQL注释里已经标清了每个字段的用途。password字段用BCrypt加密存储论文里写安全设计时有话说product.status用数字做状态不直接用字符串是为了后续查询走索引更快。商品图片存的是路径而非二进制内容这也是行业里最稳的做法——MySQL存储大字段会让表体积膨胀图片文件放在本地上传目录或对象存储里数据库只存相对路径。再看订单表和收藏表-- 订单表 CREATE TABLE orders ( id INT NOT NULL AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL COMMENT 订单编号时间戳随机数生成, product_id INT NOT NULL, seller_id INT NOT NULL COMMENT 卖家ID冗余自商品表, buyer_id INT NOT NULL COMMENT 买家ID当前登录用户, price DECIMAL(10,2) NOT NULL COMMENT 成交价下单时从商品表快照, status TINYINT NOT NULL DEFAULT 0 COMMENT 0-待确认 1-已确认 2-已取消 3-已完成, note VARCHAR(255) DEFAULT NULL COMMENT 买家留言比如约见面时间地点, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no), KEY idx_product_id (product_id), KEY idx_seller_id (seller_id), KEY idx_buyer_id (buyer_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT订单表; -- 收藏表 CREATE TABLE favorite ( id INT NOT NULL AUTO_INCREMENT, user_id INT NOT NULL, product_id INT NOT NULL, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_user_product (user_id, product_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT收藏表;订单表设计时有个容易犯的错误只存product_id不存冗余的seller_id和成交价price。这会在后续查询“我卖出的订单”时被迫去关联商品表一旦商品被下架或删除关联就断了历史订单数据直接失联。所以宁可冗余存储牺牲一点存储空间换查询鲁棒性这是实战中很实用的思路。favorite表建了联合唯一索引uk_user_product实现了“同一用户对同一件商品只能收藏一次”的业务约束同时让取消收藏的SQL可以直接用DELETE WHERE user_id? AND product_id?经纬定位。2.3 订单状态机闲置交易的5个状态与流转条件状态机是整个订单模块的核心也是论文里画E-R图、状态图时最出彩的部分。这套题目的订单流转通常是这样的待确认0买家下单后生成此时商品在页面上标记为“已被拍下”但还未真正锁定已确认1卖家在“我卖出的”列表里点击确认商品从上架中变为已卖出双方进入线下交易环节已取消2买家在待确认状态下撤销订单或卖家拒绝交易商品恢复为上架中已完成3双方完成线下交易后买家点击“确认收货”。这个状态机的核心约束是只有待确认状态下允许取消只有已确认状态下允许完成任何状态都不能跳转。对应到代码上就是在更新订单状态的Mapper里加上WHERE status 前一状态条件做乐观锁式的更新而不是让前端传一个状态过来直接覆盖。如果论文想写深一点可以把这张状态表画成流程图放进第三章“系统设计”里答辩时老师一定会顺着订单状态问并发问题。3. 用Spring Boot把核心链路跑通登录、发布、下单、确认收货3.1 项目结构与最小启动配置项目结构建议按功能模块分包config配置、controller接口层、service业务层、mapper数据访问层、entity实体类、common通用返回与异常处理。这种分层结构不管写论文还是应付答辩都最标准评委扫一眼源码目录就知道你有工程意识。最小启动配置里有一个坑必须提前避开数据库连接串的时区参数。server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/campus_trade?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver servlet: multipart: max-file-size: 5MB max-request-size: 20MB mybatis-plus: mapper-locations: classpath:mapper/*.xml configuration: map-underscore-to-camel-case: trueserverTimezoneAsia/Shanghai不写的话连接MySQL 8.x时会报时区错误。文件上传大小限制要显式配置否则默认1MB现在的手机照片一张就2MB起步上传必崩。map-underscore-to-camel-case开启后数据库的create_time能自动映射到实体类的createTime少写一堆XML里的resultMap。3.2 登录鉴权JWT 拦截器的实现校园闲置交易网站不需要做多复杂的权限体系但管理员和普通用户的接口必须区分开。这里用JWT做无状态登录是最常见也最好讲的方案用户登录成功后服务端签发一个Token前端后续请求带上Token拦截器校验通过后放行并把用户信息放进请求上下文。先写一个简单的JWT工具类public class JwtUtil { // 密钥实际项目中应放在配置文件中 private static final String SECRET campus-trade-secret; private static final long EXPIRE_TIME 7 * 24 * 60 * 60 * 1000L; public static String createToken(Integer userId, String username) { return Jwts.builder() .setSubject(username) .claim(userId, userId) .setExpiration(new Date(System.currentTimeMillis() EXPIRE_TIME)) .signWith(SignatureAlgorithm.HS256, SECRET) .compact(); } public static Claims parseToken(String token) { return Jwts.parser().setSigningKey(SECRET).parseClaimsJws(token).getBody(); } }这里用的是jjwt库的APIToken里只放了userId和username两个字段没有放密码等敏感信息。过期时间设7天是为了学生在答辩演示时不用频繁重新登录如果你放到生产环境这个时间通常缩到2小时左右并配合RefreshToken机制。接下来是拦截器这是最容易写错的地方Component public class LoginInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 放行预检请求 if (OPTIONS.equalsIgnoreCase(request.getMethod())) { return true; } String token request.getHeader(Authorization); if (token null || !token.startsWith(Bearer )) { setUnauthorized(response); return false; } try { Claims claims JwtUtil.parseToken(token.substring(7)); request.setAttribute(userId, claims.get(userId)); request.setAttribute(username, claims.get(subject)); return true; } catch (Exception e) { setUnauthorized(response); return false; } } private void setUnauthorized(HttpServletResponse response) throws IOException { response.setStatus(401); response.setContentType(application/json;charsetUTF-8); response.getWriter().write({\code\:401,\msg\:\未登录或登录已过期\}); } }拦截器里要先放行OPTIONS预检请求否则前端用axios发跨域请求时浏览器预检直接挂在半路上接口看着没问题但就是调不通。Token解析失败要统一返回401并写明原因而不是抛个500让前端瞎猜。拿到userId后放进request上下文后续所有Controller里通过request.getAttribute(userId)就能拿到当前登录人不需要每次查数据库。拦截器注册的时候注意排除登录和注册接口Configuration public class WebConfig implements WebMvcConfigurer { Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(loginInterceptor) .addPathPatterns(/**) .excludePathPatterns(/api/user/login, /api/user/register, /api/product/list, /api/product/detail/**); } }商品列表和详情接口是游客也能看的所以必须放行。管理员校验单独做一个AdminInterceptor或者直接在Controller方法里用注解判断role字段看你的时间充裕程度而定。3.3 商品发布参数校验、图片上传与状态字段的初值商品发布是卖家端的核心操作。一个容易漏掉的设计是新发布的商品默认status0待审核要等管理员在后台审核通过后才会变成status1上架中。如果没有这个审核环节两边接口都对不上论文里的“管理员模块”也少了一整块功能没写。Controller层接收表单时用Spring Validation做参数校验PostMapping(/api/product/publish) public Result publish(Valid RequestBody ProductDTO dto, HttpServletRequest request) { Integer userId (Integer) request.getAttribute(userId); return productService.publish(userId, dto); }ProductDTO里给关键字段打注解public class ProductDTO { NotBlank(message 标题不能为空) Size(max 100, message 标题不能超过100字) private String title; NotNull(message 价格不能为空) DecimalMin(value 0.01, message 价格必须大于0) private BigDecimal price; NotBlank(message 商品描述不能为空) private String description; }注意这里用的是Valid触发校验如果校验失败Spring Boot会抛MethodArgumentNotValidException在全局异常处理器里统一转成JSON返回给前端。一定不要在Controller里自己写一堆if判断时间不够写不完还漏得一塌糊涂。图片上传的路径常见做法是存在本地某个目录然后做一个虚拟路径映射让外部能访问。上传接口的写法PostMapping(/api/upload) public Result upload(RequestParam(file) MultipartFile file) { if (file.isEmpty()) { return Result.error(文件不能为空); } String originalFilename file.getOriginalFilename(); String ext originalFilename.substring(originalFilename.lastIndexOf(.)); String fileName UUID.randomUUID().toString() ext; String datePath new SimpleDateFormat(yyyy/MM/dd).format(new Date()); File dir new File(uploadPath / datePath); if (!dir.exists()) { dir.mkdirs(); } file.transferTo(new File(dir, fileName)); return Result.ok(/upload/ datePath / fileName); }用UUID重命名文件避免中文文件名和重名文件互相覆盖按日期分子目录防止单个目录下文件过多。这里生成的访问路径是/upload/2024/05/20/uuid.jpg接下来必须在配置里加资源映射Configuration public class UploadPathConfig implements WebMvcConfigurer { Value(${upload.path}) private String uploadPath; Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/upload/**) .addResourceLocations(file: uploadPath /); } }这个配置不写上传成功但前端img标签里的图片永远显示裂图属于最高频翻车点之一。3.4 下单与确认收货事务边界和乐观锁的应用下单动作涉及两张表的写操作插入订单记录、把商品状态从上架中改成已被拍下。这两步必须在一个事务里否则会出现订单生成了但商品状态还是上架中的脏数据。在Spring Boot里直接在Service方法上标注Transactional即可Transactional(rollbackFor Exception.class) public Long createOrder(Integer buyerId, Integer productId, String note) { // 1. 查商品判断状态必须是上架中 Product product productMapper.selectById(productId); if (product null || product.getStatus() ! 1) { throw new BizException(商品不存在或已被拍下); } // 2. 同一件商品不允许自己买自己的 if (product.getUserId().equals(buyerId)) { throw new BizException(不能购买自己发布的商品); } // 3. 生成订单号并插入订单表 Orders order new Orders(); order.setOrderNo(generateOrderNo()); order.setProductId(productId); order.setSellerId(product.getUserId()); order.setBuyerId(buyerId); order.setPrice(product.getPrice()); order.setStatus(0); order.setNote(note); ordersMapper.insert(order); // 4. 更新商品状态为已被拍下 Product update new Product(); update.setId(productId); update.setStatus(3); productMapper.updateById(update); return order.getId(); }这个方法已经考虑了三个边界条件商品不存在或已被拍下抛异常、自买自抛异常、事务回滚保证一致性。但高并发场景下还有更深一层的问题两个买家同时下单同一件商品前一个事务还没提交后一个查到的商品状态也是上架中。解决办法是在查询商品时加FOR UPDATE行锁SELECT * FROM product WHERE id #{id} AND status 1 FOR UPDATE或者用乐观锁方式更新商品状态时带上WHERE status 1条件如果影响行数为0说明商品状态已被改动直接抛“手慢了宝贝被拍走了”的错误。实践中用乐观锁的体验更好不会长时间锁行。放在论文里这就是并发控制小节的内容答辩时零压力。确认收货的接口同理订单状态从已确认变成已完成必须加上WHERE id? AND status1条件。前端在点击“确认收货”之前页面一直显示当前状态后端更新成功返回最新状态即可。3.5 用Redis缓存商品列表论文技术亮点与实战收益给这个项目加一个Redis做热点商品缓存是让论文“技术选型”章节立刻饱满的最快方式。核心思路首页的商品列表和搜索列表访问频率最高但数据变化不频繁第一次查数据库后把结果写入Redis后续请求直接命中缓存。public ListProductVO getProductList(int page, int size, String keyword) { String cacheKey product:list: page : size : keyword; // 1. 先查缓存 String json redisUtil.get(cacheKey); if (StringUtils.isNotBlank(json)) { return JSON.parseArray(json, ProductVO.class); } // 2. 缓存未命中查数据库 ListProductVO list productMapper.selectList(page, size, keyword); // 3. 写回缓存设置过期时间5分钟防止数据长期不一致 redisUtil.set(cacheKey, JSON.toJSONString(list), 300); return list; }这里有个细节商品列表的Redis缓存过期时间不要设太长5分钟比较合适。因为二手商品的状态变化很频繁一件商品被拍下后如果缓存还是“上架中”用户点进去会报错。加了缓存之后论文里“性能设计”章节的400字就有了答辩时也能回答“缓存与数据库一致性怎么保证”这类必问题。4. 论文与PPT答辩把代码讲成“设计与实现”4.1 论文的章节结构与每章字数参考这套项目交付物里论文是不可或缺的部分它本质上是对代码的二次包装。常见的结构安排是章节内容要点参考字数第一章 绪论校园闲置交易的背景、国内外研究现状、论文结构安排2000字左右第二章 相关技术介绍Spring Boot框架、MyBatis-Plus、MySQL、Redis、JWT2000字左右第三章 系统分析可行性分析技术/经济/操作、功能性需求、非功能性需求、用例图2500字左右第四章 系统设计总体架构图、功能模块划分、数据库E-R图、核心表结构、状态图3000字左右第五章 系统实现每个模块的界面截图核心代码逻辑说明按“用户模块/商品模块/订单模块/后台管理模块”展开3500字左右第六章 系统测试测试环境、功能测试用例表格、性能测试用JMeter截图一张、测试结论1500字左右第七章 总结与展望完成的工作、不足之处、后续改进方向800字左右系统实现那一章最容易写成代码堆砌大杂烩评审最不喜欢看大段大段贴代码的论文。正确姿势是每个功能小节先写一段业务逻辑描述再放一个关键方法的核心代码片段控制在15行左右最后用1~2句话说明这段代码实现了一个什么业务约束。比如订单模块就重点贴状态更新的乐观锁条件而不是把整个Service类几十行全盘复制。4.2 PPT的10页结构与演示顺序答辩PPT一般控制在10页左右每页讲1~2分钟配上现场系统演示正好10分钟。结构建议是第1页题目、答辩人、指导教师——名字不念串就行第2页项目背景与研究意义——两句话带过不要念长篇第3页技术栈图谱——Spring Boot、MyBatis-Plus、MySQL、Redis用表格列出每个技术解决什么问题第4页系统功能模块图——画一个树状图用户端/管理员端两条分支第5页系统架构图——浏览器→Controller→Service→Mapper→MySQL标注Redis在哪一层第6页数据库设计——只放核心的E-R图或订单状态流转图第7页系统演示——直接切到运行环境这是全场核心前面页面不要拖太久第8页核心难点与解决方案——讲乐观锁控制商品并发下单、JWT无状态登录、图片本地存储与路径映射这三点第9页系统测试结果——放用例表格截图第10页总结与展望——客气收尾感谢老师提问。演示的时候一定要按角色切换账号演示。先切普通卖家账号发布一件商品再切管理员账号在后台审核通过然后切另一个买家账号去搜索并下单最后回到卖家账号确认订单。这条完整链路走完评审对系统的信任度会高很多。4.3 答辩被问概率最高的5个问题与应答思路第一个必问题是“为什么选Spring Boot而不是SSH或SSM”。应答要点Spring Boot简化了配置内嵌Tomcat不用单独部署自动装配特性让开发专注于业务逻辑同时社区生态成熟适合快速交付项目。第二个必问题是“订单并发情况下怎么防止一件商品被多人买走”。应答思路是先讲数据库乐观锁更新商品状态时带条件WHERE status1影响行数为0说明被抢再讲Redis缓存商品状态但最终以数据库更新结果为准。第三个问题是“JWT和传统Session登录有什么区别”。应答要点Session存储在服务端集群部署时要考虑Session共享JWT无状态Token存在客户端服务端只需要验签天然支持分布式环境更适合前后端分离架构。第四个问题是“一张表大概有多少条数据性能如何”。这个必须提前造数往商品表插个几百条测试数据论文测试章节放JMeter压测结果比如并发100时接口平均响应时间120ms吞吐量每秒80个请求。别被问到的时候答“测试环境没有数据”。第五个问题是“做过哪些安全性考虑”。应答思路密码BCrypt加密存储、JWT拦截器保护非公开接口、上传文件格式限制、SQL语句全部使用预编译避免注入。5. Spring Boot交易网站避坑清单5个让你当场翻车的细节5.1 图裂404上传成功但页面加载不出图片现象文件上传接口返回成功数据库里也存了路径但前端img标签的src为404。刷新、重启都没有用。原因Spring Boot默认的静态资源映射只覆盖classpath:/static/等目录你上传到本地磁盘绝对路径下的文件并没有被映射到URL上。解决在WebMvcConfigurer里添加资源映射把/upload/**这个虚拟路径指向磁盘的物理路径也就是3.3节里贴的那段配置。上传文件的保存路径用配置文件维护不要硬编码在代码里更不要放到项目打包后的目录下。5.2 商品超卖两个买家同时下单同一本书现象测试阶段两个账号同时抢一件商品两个订单都创建成功了商品状态却是已卖出。原因查询商品状态和更新商品状态不是原子操作。事务A查到状态为1事务B也查到状态为1A更新成已卖出B再更新时虽然覆盖了但订单已经插入了。解决更新商品状态时在update set status3 where id? and status1这个SQL上做版本控制updateById的返回值是0就说明已经被别人抢了直接抛异常回滚。或者用select ... for update锁行。千万不要只用代码里的if判断来挡并发那个只能骗骗自己。5.3 拦截器把登录接口拦截了登录变成死循环现象启动项目后调用登录接口返回401未授权但明明登录接口是不需要鉴权的。原因拦截器注册时addPathPatterns(/**)通配了所有路径excludePathPatterns里的路径写错了常见的是后端接口统一带/api前缀但排除路径漏写了或者排除的是/user/login而接口实际是/api/user/login。解决把注册拦截器的配置放在一个独立的WebConfig类里排除路径写绝对路径启动时在控制台打印出拦截器匹配的路径清单肉眼确认一遍。前端联调时遇到401优先查这里不要怀疑前端代码。5.4 修改商品时未填的字段被更新成null现象前端只传了标题和价格没有传描述和分类保存后数据库里的description字段变成null页面详情只剩残缺信息。原因MyBatis-Plus的updateById默认策略是字段为null也更新你用实体类做更新时没有从前端带过来的字段自然就是null覆盖掉了原有的值。解决给实体类的字段加配置策略在MyBatis-Plus全局配置里设置mybatis-plus: global-config: db-config: update-strategy: not_null这样更新SQL只会拼接非空字段没传过来的字段保持原值不变。这是MyBatis-Plus非常经典的一个坑答辩时你自己主动提出来老师会觉得你有实战经验。5.5 演示现场数据库连不上时区、端口、防火墙三连问现象评委老师让你现场跑一下系统结果启动报错Communications link failure。原因第一层是MySQL没启动第二层是serverTimezone配置不对高版本MySQL驱动强制要求显式时区第三层是你笔记本连了实验室WiFi防火墙拦了3306端口。解决答辩前一天做一次完整预演把IDEA启动Spring Boot、Navicat连接数据库、前端页面三个流程在自己电脑上各跑两遍。所有配置不要依赖网络上的共享数据库就用本机MySQL连接串里的时区写成Asia/Shanghai。手机开热点也连不上时检查MySQL的bind-address是不是127.0.0.1改成本机局域网IP或者直接注释掉重启服务。6. 把系统做成“能讲的完整项目”最后一天值得做的五件事很多学生代码写完了但演示时只能干巴巴地点几个页面没有数据、没有对比、没有细节。答辩前如果还剩一天的时间按优先级做这几件事第一是写一个数据初始化脚本往用户表里插两个普通用户和一个管理员商品表里插20件分布在各个分类的商品模拟不同成色和价格区间订单一到两笔这样演示时不用现场造数据对抗尴尬。第二是准备两个浏览器窗口一个登录卖家一个登录买家演示下单时两个窗口切换比反复退出登录更流畅。第三件事是检查所有前端页面的空状态处理比如商品列表没数据时显示“暂无闲置物品”订单列表为空时显示“还没有相关订单”这比空白页面让评委舒服得多。第四件事是把项目打包部署一次执行mvn clean package构建出jar包用java -jar命令跑起来确认没有依赖本机IDEA环境。很多学生平时都是在IDEA里点运行的打包后才发现配置文件里的路径写死导致启动失败提前做一遍相当于买了后悔药。最后一件事是给核心接口写一份简单的README测试清单把每个接口的请求方式和预期响应贴进去答辩时如果老师要现场看你接口直接按清单演示。这几年陆陆续续帮人看过不少同类毕设说句实在话校园闲置物品交易网站这个题目本身不卡人卡人的永远是那些你以为不是问题的问题图片路径没映射、输入框没做校验、商品状态更新没加并发控制、答辩PPT念了十分钟没演示系统。把这些细节按上面这套流程走一遍这个项目就不只是能跑而且是能讲出设计亮点的完整作品。希望帮到你。本文还有配套的精品资源点击获取