基于Spring Boot的二手滑板交易系统毕设：数据库设计与状态机解析

去年带一个学弟做毕设，他的选题就是基于Spring Boot的二手滑板交易系统。代码跑起来的那天他特别兴奋，结果一周后模拟答辩，导师一句话就把他问住了：“你这个订单状态是怎么流转的？用户下单之后，商品表里那条数据什么时候变成已卖出？”他支支吾吾答不上来。代码能跑，但讲不清楚，这在毕设里是致命的。

其实类似的问题几乎每个做Java毕设的人都会遇到。Spring Boot项目的代码太容易“抄”了，Gitee上一搜一大堆，可真正决定你能不能过答辩、能不能在面试里把项目讲明白的，是你有没有吃透这套系统背后完整的前后端逻辑、数据表设计和状态流转规则。今天我就以这套二手滑板交易系统为例子，把从需求拆解、数据库设计、核心功能实现到调试定制、文档撰写的完整流程，掰开揉碎地讲一遍。不管你是从零开始自己写，还是手上已经有一份全套代码准备消化吸收，这篇文章都能帮你在最短时间内把项目变成“你的项目”。

1. 别急着跑代码：先弄清楚这套二手交易系统到底在解决什么问题

很多人拿到项目的第一反应就是配环境、导数据库、启动服务，一条龙下来发现首页能打开了，就觉得完事大吉。这个习惯非常危险。10分钟的演示谁都会做，但答辩有20分钟，面试有30分钟，你总得说出点设计上的东西。所以在打开IDE之前，先花半天时间把“需求”和“系统边界”想清楚。

1.1 二手交易系统和标准电商系统最大的区别：没有库存，只有唯一商品

普通电商系统里，商品=类目+SKU+库存，用户下单买的是“一堆同款商品中的一个”。但二手滑板交易系统不是这个逻辑。一个滑板挂在平台上，它是唯一的一件商品，一个人买走，它就没了。这个本质区别决定了所有的表结构和业务逻辑。

为什么强调这一点？因为一旦你理解了这个核心差异，你再看数据库设计、再看状态机，就全通了：

• 滑板商品表里的status字段非常关键，它从“在售”变成“已卖出”是一次性的，不能回滚到“在售”，只能进“下架”或“已完成订单”。
• 下单的时候不是扣库存，而是把商品状态从“在售”改成“待支付 / 已卖出”，这个动作必须加条件，否则两个人同时下单就会超卖。
• 用户是卖家的同时也是买家，所以用户表不需要分成“买家和卖家居多”两套体系，一张用户表加一个角色字段或者干脆不分角色都行，靠外键关联即可。

这些点随便抓出来一个，都能成为答辩时你主动讲解的亮点。导师最喜欢听到的不是“我用了Redis缓存”，而是“我这里的业务逻辑有个并发问题，我是这么解决的”。

1.2 系统的两条主链路：C端买家链路和B端卖家/管理链路

二手滑板交易系统的角色可以分成两类：普通用户（同时是卖家和买家）和管理员。围绕这两个角色，功能可以拆成两条主链路。

用户链路要搞定：注册登录 → 发布滑板商品 → 浏览/搜索/筛选商品 → 查看商品详情 → 下单购买 → 支付（模拟或真实）→ 发货/收货 → 评价/留言。

管理员链路要搞定：后台登录 → 用户管理（冻结/解冻）→ 商品管理（审核/下架违规商品）→ 订单监控 → 基础数据统计（可选）。

我见过很多人的系统功能列表写得花里胡哨，什么“个性化推荐”“在线聊天”“积分商城”全都堆上去，结果答辩时自己都维护不过来。二手交易系统的核心价值就是信息撮合和交易保障，把上面这两条链路做到位，功能已经足够完整。如果精力有余，再加收藏、站内留言、分类筛选，这些已经是加分项了。

1.3 技术选型：为什么Spring Boot是这个项目最合适的底座

用Spring Boot做Java毕设已经不是什么小众选择了，它的优势非常直白：

• 起步快：内嵌Tomcat，一个main方法就能启动，不需要单独部署Web容器。
• 生态成熟：配合MyBatis-Plus、Spring Security（或拦截器）、JWT，CRUD和各种权限控制都能在很短的代码量内落地。
• 面试认可度高：Java后端岗位的日常开发几乎都在跟Spring家族打交道，做完这个项目，你在简历上写“熟悉Spring Boot开发”是站得住脚的。

具体到这套系统，我建议的技术栈是：Spring Boot 2.x + MyBatis-Plus + MySQL 5.7/8.0 + Vue 2/3（或简单的Thymeleaf模板），鉴权用JWT，前端用Element UI做后台管理界面。这套组合足够覆盖绝大多数毕设要求，而且每一步都有海量的参考资料。

不要一上来就纠结用Spring Cloud微服务还是用Sa-Token还是用Redis。二手交易系统的业务量级远没有到需要分布式方案的程度，选型过度反而是答辩时被追问的雷区。用最简单可靠的工具把业务逻辑做清楚，这才是毕业设计该有的样子。

2. 数据模型是地基：从滑板商品到订单状态机的完整设计

Spring Boot项目里，所有的功能实现最后都落到SQL和表结构上。表设计得好，后面的代码写起来行云流水；表设计得潦草，后面每写一个接口都想骂人。我直接给出一套参考性的表结构，结合字段说明和设计理由讲清楚。

2.1 用户表：一张表承载两种角色

用户表是系统的基础，字段设计不必非常复杂。

为什么密码不用MD5？因为MD5撞库太容易了。Spring Security的BCryptPasswordEncoder加盐哈希是标配，代码也就一行的事，说出来却能让老师觉得你安全意识到位。

为什么角色不拆成用户表、角色表、权限表三张？因为这是毕设，不是大型后台权限平台。一个role字段就够，管理员和用户的操作完全靠后端接口的统一拦截来区分，不需要做成RBAC模型。你在答辩时直接说“考虑到系统规模和实际场景，我采用了简化角色模型”，这是合理的工程取舍。

2.2 滑板商品表：垂直品类字段是亮点

二手滑板不是普通二手商品，它有自己垂直品类的特征。这些特征字段是让项目看起来不像通用商城代码拼装的关键证据。

这个表有两个地方值得展开。

第一个是多图存储方案。我直接用images_json存一个JSON字符串，比如["/upload/001.jpg","/upload/002.jpg"]。这不违反数据库设计范式吗？严格说违反，但毕设项目里这是极其务实的做法。好处很明显：不需要额外建一张图片子表，查商品详情一次查询就能拿到全部图片，代码量直接减半。你要跟导师解释清楚的是：图片是跟着商品一起展示的，不会单独被检索，JSON存储在这个场景下是合理的优化。如果你的导师比较传统，你也可以改成图片子表，但我觉得JSON方案完全能自圆其说。

第二个是滑板品类的垂直字段。这些字段不是什么attr1、attr2这种偷懒做法，而是真实的滑板二手交易里买家关心的核心信息。品牌决定了二手价，成色决定了折价率，类别决定了适用人群。答辩时你就可以说：“我通过调研闲鱼滑板类目的用户关注点，设计了这些垂直属性字段，让买家在列表页不需要点进详情就能判断商品是否适合自己。”这句话一出来，项目的真实性和调研深度立马不一样。

2.3 订单表：一个status字段走完整个交易生命周期

订单表是整个系统最核心的表，也是面试官和导师最爱追问的地方。

订单状态机设计如下：

0 待支付 → 1 已支付（待发货） → 2 已发货 → 3 已确认收货 → 4 已完成 ↘ 5 已取消

为什么要用统一的一个status字段，而不是给订单表加一堆is_paid、is_shipped、is_finished布尔字段？因为状态之间是互斥的，一个订单不可能同时处于已支付和已发货之间的一对多关系中。用单个状态字段加状态机枚举，每次状态流转都可以在代码里通过if判断先后顺序，避免出现“订单还没支付就已经发货”这种脏数据。

订单号order_no也有讲究。我推荐用时间戳 + 用户ID后六位 + 随机数生成，比如20250111153022 + 000123 + 487。不要用数据库自增ID当订单号展示给用户，一是泄露平台订单总量，二是看起来非常业余。就算不用分布式雪花算法，手动拼一个字符串订单号也就五六行代码，但这个细节很能体现你的工程素养。

2.4 收藏表、留言表与分类表：低频但完整

这几张表没有技术难点，但要注意设计的合理性：

收藏表：id、user_id、goods_id、create_time，联合唯一索引(user_id, goods_id)，防止重复收藏。

留言表（如果要做评论或留言）：id、goods_id、user_id、content、create_time，按商品ID索引即可。滑板的成色主观性很强，买家留言问“轮子磨损怎么样”“轴承还顺不顺”，这是业务上的真实需求，做上去非常自然。

分类表：如果你不想用固定的category字段，也可以建一张category表，字段只有id、name、sort。我更推荐固定字段，因为滑板品类就那几种，固定字段直接配合枚举展示，代码更简单。

数据表之间的关联，我不建议在数据库层面建立真正的物理外键。全部用逻辑外键，也就是说表里存了user_id、goods_id，但FK约束不加。原因是在实际开发里，物理外键会让删除操作变得极其痛苦，而且性能有一定损耗。只要在代码层面保证数据一致性，逻辑外键是业内更普遍的做法。这一点同样可以在答辩时主动说明，导师通常会很认同。

3. 核心交易链路的实现逻辑：发布、下单、确认收货怎么一步步走通

表结构理清了，接下来就是核心业务代码。这里我不贴完整代码，而是把每一步的关键实现思路和重要代码片段讲透。你写期末项目或面试讲项目时，这些就是你的“讲解索引”。

3.1 发布滑板商品：前端表单、文件上传与数据落库

发布页面需要提交的信息包括：标题、描述、分类、品牌、成色、原价、转让价、封面图、多图。前端提交方式用multipart/form-data，因为要包含文件。

后端接口大致逻辑：

@PostMapping("/goods") public Result publish(@RequestParam("file") MultipartFile[] files, GoodsVO goodsVO, HttpServletRequest request) { // 1. 从JWT中解析当前登录用户ID Long userId = JwtUtil.getUserId(request); // 2. 保存上传的图片文件 List<String> urls = fileService.uploadImages(files); // 3. 组装商品对象 Goods goods = new Goods(); BeanUtils.copyProperties(goodsVO, goods); goods.setUserId(userId); goods.setCoverUrl(urls.get(0)); goods.setImagesJson(JSON.toJSONString(urls)); goods.setStatus(1); // 直接上架 goods.setCreateTime(new Date()); // 4. 落库 goodsMapper.insert(goods); return Result.success(goods.getId()); }

这里有一个毕设项目里极其常见的坑：图片上传后前端访问不到。原因通常是项目配置了拦截器或者Spring Security放行规则，把/upload/**路径拦掉了。我用的是自定义拦截器方案，所以需要在WebMvcConfigurer里显式放行：

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

如果你不用拦截器，那要确保Spring Boot没有把upload静态资源目录排除掉，否则同样会出现404。这个坑我在后面调试部分还会详细讲，因为几乎80%的人都会踩到。

3.2 浏览与搜索：一张列表页背后的完整条件拼装

首页商品列表通常需要支持三个筛选维度：分类、成色区间、价格区间，以及关键词搜索。如果直接用SQL注解写死，那条件分支写到崩溃。这里用MyBatis-Plus的QueryWrapper非常顺手：

public Page<Goods> listGoods(int page, int size, GoodsQuery query) { Page<Goods> pageInfo = new Page<>(page, size); QueryWrapper<Goods> wrapper = new QueryWrapper<>(); wrapper.eq("status", 1); // 只查在售 wrapper.like(StringUtils.isNotBlank(query.getKeyword()), "title", query.getKeyword()); wrapper.eq(StringUtils.isNotBlank(query.getCategory()), "category", query.getCategory()); wrapper.le(query.getMaxPrice() != null, "current_price", query.getMaxPrice()); wrapper.ge(query.getMinPrice() != null, "current_price", query.getMinPrice()); wrapper.orderByDesc("create_time"); return goodsMapper.selectPage(pageInfo, wrapper); }

分页参数current和size从前端传过来，MyBatis-Plus会自动拼LIMIT，返回的Page对象里直接带total、records等字段，前端分页组件拿到直接渲染。这块代码不难，但很实用，熟悉之后你写任何后台列表都会非常快。

还有一个容易被忽略的功能：浏览量view_count的自增。方案很简单，在商品详情接口里同步执行update goods set view_count = view_count + 1 where id = ?即可。但需要注意不能放在每次前端调用详情接口的必经之路上，否则前端加载一次详情、图片懒加载再触发一次，浏览量就翻倍了。我的方案是只在用户点击进入详情页时调用一次，且接口幂等性不做强要求，毕竟浏览量统计本身允许一定误差。

3.3 下单流程：并发不超卖的关键一行SQL

二手商品没有库存，下单冲突的临界条件就是同一个用户和另一个用户同时点“立即购买”。这一步必须做原子性的条件更新，防止两个人都下单成功。

先看代码：

@Transactional public Order createOrder(Long goodsId, Long buyerId, String remark) { // 1. 查询商品 Goods goods = goodsMapper.selectById(goodsId); if (goods == null || goods.getStatus() != 1) { throw new BizException("商品不存在或已下架"); } // 2. 条件更新：只有status为1（在售）时才能改成3（已卖出） int rows = goodsMapper.updateStatusById(goodsId, 1, 3); if (rows == 0) { throw new BizException("手慢了，商品已被拍下"); } // 3. 创建订单 Order order = new Order(); order.setOrderNo(generateOrderNo(buyerId)); order.setGoodsId(goodsId); order.setSellerId(goods.getUserId()); order.setBuyerId(buyerId); order.setTotalPrice(goods.getCurrentPrice()); order.setStatus(0); order.setCreateTime(new Date()); orderMapper.insert(order); return order; }

核心逻辑我标注了第2步：条件更新。UPDATE语句自带行锁，两个请求同时执行时，只有一个请求能更新成功，另一个的rows是0，直接返回“已被拍下”。这个处理方式本质上就是一个乐观锁思想，比查出来再判空再更新的“三步操作”安全得多。

你可能要问：那万一用户下单后不支付怎么办？好问题。订单状态还停在“待支付”，商品状态已经是“已卖出”了。处理办法有两种：

方案一（简单）：超时自动取消。定时任务扫描超过30分钟未支付的订单，将订单置为“已取消”，把商品状态改回“在售”。毕设里用一个@Scheduled定时注解就能实现。

方案二（演示用）：在用户取消订单时回滚商品状态。真实二手平台很少这么干，因为商品可能在等待期间已经被另一个买家收藏或咨询了。但毕设演示完全够用。

我两个方案都实现了，答辩时可以主动提“这里我设计了订单超时自动关单，避免死单占用商品状态”，这会成为你的亮点。

3.4 订单状态推进的完整链路

从下单到完成，买卖双方各有两个核心操作：

买家操作支付和确认收货。支付通常走模拟支付，前端弹窗点击“确认支付”即调用支付接口，把订单从0改成1，并记录pay_time。确认收货把订单从3改成4（或直接改到完成态），记录confirm_time。

卖家操作发货。发货接口把订单从1改成2，记录ship_time。这里还需要考虑一个业务场景：卖家发货后，买家才能看到物流信息（通常只是简单填个物流单号）。

每个状态变更接口都要注意三件事：

第一，判断当前操作人是不是该订单的卖家或买家。seller_id和buyer_id必须和当前登录用户匹配，否则任何用户都能改任意订单状态，这是严重越权漏洞。面试时被问到安全问题，这是标准回答点。

第二，接口幂等。前端按钮操作有时候会因为网络抖动重复提交，后端要在状态判断上挡住。比如对已经处于“已支付”状态的订单再次调用支付接口，应当直接返回“当前状态不可操作”或“重复操作”，绝不能把订单状态从1覆盖成1然后再推进到2。

第三，使用@Transactional保证事务一致性。订单状态和商品状态的变更要么同时成功，要么同时回滚。Spring的声明式事务在这个场景下非常省心，一行注解搞定。

3.5 留言与收藏：高复用的小模块

这两个模块本质上是两张表的CRUD，但在交互设计上有个小技巧值得说。

收藏：列表页在商品卡片右上角放一个小图标，前端点击时调用/collect接口，后端insert into collect或delete。前端根据返回值实时切换图标状态。如果用JWT，用户ID从token解析。

留言：商品详情页底部展示所有留言，发布留言的 input 框只在登录后显示。滑板这类垂直商品的留言往往是“能小刀吗”“轴承多久换的”，显得非常真实，对项目演示效果特别好。

这两个模块代码量大约100行，但在功能完整性上价值很高。答辩时你可以说：“我在基础交易链路之外增加了收藏和留言功能，提升买家与卖家之间的互动效率。”

4. 前后端分离中的鉴权与联动：Token、跨域与前端页面背后的逻辑

现在的毕设项目十有八九是前后端分离的。前端Vue，后端Spring Boot，两边通过JSON交互。这个架构没问题，但它会带来两个绕不开的技术点：鉴权和跨域。

4.1 JWT还是Session？我的选型和理由

Spring Boot做登录鉴权有两大流派：Session和JWT。

Session方案：用户登录后把用户信息存在服务端内存或Redis，给前端返回一个JSESSIONID存在Cookie里。优势是实现简单，缺点在前后端分离场景下非常明显：前端如果不在同一个域名下访问，Cookie的跨域同名问题会折腾死你，而且服务端需要维护会话状态。

JWT方案：登录成功后生成一个包含用户ID、用户名、过期时间的加密令牌返回给前端，前端每次请求在Authorization头里带上。服务端无状态，不需要存储会话，天然适合前后端分离。

我推荐JWT。虽然JWT有无法主动失效的缺点，但毕设系统没有高安全性要求，用JWT的好处是：

• 前端代码里处理token的逻辑非常标准，每一步都有成熟封装
• 后端拦截器实现简单，一次配置全局生效
• 面试时讲JWT的原理会显得你对现代Web开发有了解

实现上分三步：

第一步，登录成功生成token：

String token = JwtUtil.createToken(user.getId(), user.getUsername());

第二步，写一个拦截器，在preHandle中验证token：

@Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token = request.getHeader("Authorization"); if (StringUtils.isBlank(token)) { throw new BizException(401, "未登录"); } Long userId = JwtUtil.parseToken(token); request.setAttribute("userId", userId); return true; }

第三步，在WebMvcConfigurer注册拦截器并放行登录、注册、商品列表、商品详情等公开接口：

registry.addInterceptor(jwtInterceptor) .addPathPatterns("/api/**") .excludePathPatterns("/api/auth/login", "/api/auth/register", "/api/goods/list", "/api/goods/detail/**", "/upload/**");

这样设计之后，整个项目内的接口权限控制就成型了。管理员专属接口（比如用户冻结、商品强制下架）再加一层role判断即可，通常是在拦截器里解析token拿到角色，或者在各业务接口里通过工具方法校验。

4.2 跨域配置：前端3000端口访问后端8080端口的必配项

Vue开发服务器默认跑在http://localhost:5173（Vite）或http://localhost:8081，后端是http://localhost:8080，浏览器层面前端端口不同，就属于跨域请求。不配置后端允许跨域，前端调用接口时会直接报CORS错误。

最简单的配置方式是在后端加一个配置类：

@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); } }

这里有个小细节，allowCredentials(true)和allowedOriginPatterns("*")配合使用才不会报错。如果只用allowedOrigins("*")，在开启携带凭证时会报“Cannot allow credentials with wildcard origin”。

如果前端项目通过Nginx反向代理部署，把/api/前缀代理到后端服务，就不存在跨域问题了。但我建议你在开发阶段还是配上CORS，省得每次都要靠Nginx调试。

4.3 前端路由守卫：为什么后端做了权限控制，前端还要再做一遍

很多人的前端页面是拿到项目就跑，完全没看过路由文件。但实际上前端路由守卫是一个非常好的答辩知识点。

Vue Router的路由守卫可以这样写：

router.beforeEach((to, from, next) => { const token = sessionStorage.getItem("token"); if (to.meta.requiresAuth && !token) { next("/login"); } else { next(); } });

它的作用：用户未登录时，不能直接通过修改URL访问个人中心、发布商品、订单管理等页面。

那后端拦截器不是已经挡了未登录请求吗？前端为什么还要做？答案是用户体验。后端拦截只能拦接口，前端不做守卫的话，用户未登录直接访问/publish页面，看到的是一堆空数据或接口401报错，页面会闪一下再跳登录页，非常不友好。而且如果部署时后端接口误配置了放行，前端守卫就是第二道防线。

前后端双重校验是实际项目里最常见的设计，你在答辩时这个点能讲出来，说明你对web安全有实际认知，而不是只会调接口。

4.4 接口规范：REST风格让项目结构一目了然

这套系统的接口设计遵循REST风格，即使前端页面再复杂，接口清单也保持稳定：

• POST /api/auth/register、POST /api/auth/login：认证
• GET /api/goods/list、GET /api/goods/{id}：商品
• POST /api/goods：发布商品
• PUT /api/goods/{id}：修改商品信息
• DELETE /api/goods/{id}：下架/删除商品
• POST /api/order：创建订单
• GET /api/order/my：我买到的/我卖出的
• PUT /api/order/{id}/pay、PUT /api/order/{id}/ship、PUT /api/order/{id}/confirm：订单流转
• GET /api/user/info：用户信息

统一响应结构也很重要，我通常用一个Result类包装：

{ "code": 200, "message": "success", "data": {} }

前端在axios响应拦截器里对code统一判断，等于给全局的错误处理定下基调。很多半成品项目的接口返回格式五花八门，有直接返回字符串的，有返回Map的，前端处理逻辑写得极其痛苦。好的接口规范是项目工程化程度的重要指标，也是代码审查和答辩时的隐形加分项。

5. 调试与定制：毕设交付中最容易翻车的三个环节

有了完整的代码结构，接下来就是真刀真枪把项目跑起来。我在帮学弟调试这套系统时，遇到了非常多重复的问题，我把其中最典型的三个写出来，都是可以直接对着检查清单操作的。

5.1 环境翻车：JDK、Maven依赖与MySQL版本三连坑

Spring Boot 2.x对JDK版本有明确要求，我用的是2.7系列，要求JDK 8或11。如果你本地装了JDK 17甚至21，启动时可能会报Unable to make protected final java.lang.Class这类反射错误。解决办法有三个：

一是换JDK版本，装一个8，项目配置里把JDK版本指过去就行。二是升级Spring Boot到3.x，但3.x要求JDK 17，而且javax包要全改为jakarta，改动成本高。三是如果只是测试，可以在启动参数里加--add-opens，但这是治标不治本。

Maven依赖冲突也很常见，尤其是一些项目的pom里同时引入了不同版本的mybatis-plus-boot-starter和jdbc依赖，导致启动时Property 'sqlSessionFactory' or 'sqlSessionTemplate' are required。

遇到这种问题，先看依赖树：

mvn dependency:tree -Dverbose

找到重复的jar包，在pom里用<exclusions>排除掉一个。这个操作在很多正式开发场景也常用到，学会排查依赖冲突，能省下大量自闭时间。

MySQL方面最大的坑是版本差异。5.7和8.0的驱动类名、连接URL参数都不一样：

spring: datasource: url: jdbc:mysql://localhost:3306/skate?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai username: root password: ****** driver-class-name: com.mysql.cj.jdbc.Driver

MySQL 8.0必须用com.mysql.cj.jdbc.Driver，5.7也可以用它；但如果项目里写的是老版的com.mysql.jdbc.Driver，8.0会直接启动失败。另外如果你本地是MySQL 8.0，记得检查时区配置，否则数据库连接可能因为时区问题抛异常。

5.2 图片上传后访问404：拦截器放行配置的优先级问题

图片上传本身简单，但上传完发现前端访问不到就头大了。这套系统的上传接口通常是这样：

String fileName = UUID.randomUUID().toString().replace("-", "") + "." + suffix; File dir = new File(uploadDir); if (!dir.exists()) dir.mkdirs(); file.transferTo(new File(dir, fileName)); return "/upload/" + fileName;

访问/upload/xxx.jpg时404，排查步骤按顺序走：

第一步，确认图片真实存在磁盘里。直接去uploadDir对应的目录看文件。不存在就是上传逻辑问题，存在才是映射或拦截问题。

第二步，确认application.yml里的资源映射配置。在WebMvcConfigurer里没有配置addResourceHandlers，那静态资源访问默认找classpath:/static/、classpath:/public/等目录，磁盘上的/upload不在默认范围内，就会404。

第三步，确认自定义拦截器有没有放行/upload/**。如果你登录拦截器把/api/**都拦了，而前端图片的请求路径正好是/api/upload/xxx，那么也要在排除列表里加/api/upload/**。

我曾经见过一个项目是把上传接口写在/api/upload下，静态资源路径却是/upload/xxx，结果前后端路径对不上，图片能上传但列表页全部裂图。这种问题用浏览器的“开发者工具→Network”看一下请求URL和响应码，基本都是1分钟定位，不需要瞎猜。

5.3 订单状态不同步：前端页面展示逻辑与后端返回不一致

这个场景我遇到过很多次：商品已经卖出，前端列表里状态还是“在售”。排查起来通常有两个原因。

第一个原因最简单，前端修改商品列表数据后没有重新请求接口，而是操作了本地缓存。比如用户点“下架”后，前端只是把按钮状态改了，没有刷新列表数据。解决方式是所有会改变状态的操作（下单、下架、发货、确认收货）完成后，都在axios回调里重新调用列表数据。这个属于前端交互逻辑问题，不算后端bug。

第二个原因是后端接口在返回订单列表时，用了一条SQL去查商品表，但商品表的status并没有在订单创建时同步更新。这说明代码里下单时可能只insert了订单，漏掉了update goods set status=3。我学弟当时就是只写了下单接口，商品状态完全没动，导致订单创建成功但商品还挂着卖。这个问题在后端验证特别简单，直接看sys_log或手动查一下goods表是否在orders插入的时间点附近有更新记录即可。

从工程角度说，订单状态和商品状态的一致性强制关联是业务正确性的底线，也是最基础的测试用例。在文档里把这张状态流转图写清楚，你的系统测试章节就有了核心内容。

5.4 定制需求快速定位：改轮播图、改字段、改权限的常规路径

毕设拿到手经常需要二次定制，常见就这几类：

• 改Logo和首页文案：前端public/index.html的<title>、.vue文件里的翻译文案，直接搜索即可。我的建议是全局搜索中文字符串，一次改完。
• 新增一个商品字段：数据库加列，实体类加属性，前端表单加组件，前后端VO各加一个字段，大概耗时半小时，重点是不要忘记GoodsVO和实体类之间属性的BeanUtils.copyProperties映射，不然新字段永远传不到数据库。
• 改角色权限：如果要在后端接口增加“仅管理员可访问”的校验，直接在拦截器里解析完token之后，再判断role字段。

这些定制的本质是你能不能在拿到代码后，快速建立起“字段流向”的敏感度：数据库列 → 实体类 → Mapper XML → Service → Controller → VO → 前端页面。沿着这条链路走，任何功能改动都不会迷茫。

6. 文档与答辩：代码写得再好，说不清楚照样白搭

最后这部分很多人不重视，但它恰恰是毕业设计拿高分的关键。你要清楚，导师不会一行行去读你的代码，他判断你项目做得好不好，主要依据就是你的LW和答辩表现。

6.1 毕业设计文档（LW）的结构建议

这套二手滑板交易系统的LW，我建议按如下章节组织：

• 绪论：写二手交易平台的发展背景，重点突出垂直品类（滑板）市场的现状和痛点，比如闲鱼上滑板搜索商品质量参差不齐、信息不透明等。这一部分写你的选题动机和研究意义，要有具体的场景感。
• 相关技术介绍：Spring Boot、Vue、MyBatis-Plus、MySQL、JWT，每个技术写是什么、为什么用它、在项目中用在哪里。不要整段抄百度百科，要做到“技术选型与项目需求的映射”。
• 需求分析：画用例图、功能需求（买家、卖家、管理员）、非功能需求（性能、安全性、易用性）。
• 系统设计：架构设计（前后端分离架构图，逻辑图不是流程时序图，可以用静态示意图）、功能模块划分。
• 数据库设计：ER图 + 每张表的字段说明表格。这个章节很好写，因为表结构本来就是你设计的。
• 系统实现：核心功能模块的代码分析和关键截图。注意不要贴大段代码，重点是贴核心代码段并配合业务逻辑解释。
• 系统测试：功能测试（每个模块的测试用例表格）+ 性能测试（用JMeter简单压测一下，能给出吞吐量和平均响应时间数据）。
• 总结与展望：写你做完之后发现了哪些不足，比如缺少在线聊天、缺少信用评价体系、未来可以引入推荐算法等。

6.2 答辩前必须完成的三件事

第一件事：把部署过程重新走一遍。不要用自己电脑上已经跑起来的环境直接答辩。从安装MySQL开始，一步步建库、导数据、启动后端、启动前端，确认冷启动不出错。我见过太多人因为之前环境配置过一遍就能跑，答辩时换了一台演示电脑就各种报错，场面极其尴尬。

第二件事：把核心代码的关键路径画一遍。在纸上画出“用户下单”这条链路经过的表和状态变化流程，然后用自己的话讲一遍：用户点购买 → 前端请求/api/order→ 后端条件更新goods表status → 插入orders记录 → 返回订单号 → 前端跳转支付页。你会发现画完之后，所有相关代码你在哪里改过都记得一清二楚。

第三件事：准备3个“我踩过的坑”。别人问“项目里你遇到的最大困难是什么”时，你不能说“没遇到什么困难”，也不能说“调Bug调了好久”。你要说一个具体的、有技术含量的坑。比如“我在做商品图片上传时，发现上传后前端无法访问，定位是资源映射未配置+拦截器未放行两个原因叠加，后来通过配置addResourceHandlers解决”“在订单状态流转时发现用户重复提交支付请求会导致状态混乱，所以我通过条件更新和状态判断解决了幂等性问题”。这种话一出来，导师会觉得你的项目是真实做出来的，不是流水线代做的。

6.3 答辩演示的操作清单

演示环节只有一个原则：演示功能要沿着一条业务线完整走通，而不是在首页胡乱点。

我的建议演示顺序是：

• 首页展示滑板商品列表、分类导航 → 搜索一个关键词 → 点进详情
• 注册/登录一个用户账号
• 发布一个滑板商品（这时候你最好提前准备几张滑板图片，现场上传）
• 切换到另一个用户账号，搜索刚才发布的商品 → 下单 → 模拟支付
• 切换到卖家账号，看到订单，发货 → 补一个确认收货和留言
• 最后切管理员，展示用户管理和商品管理功能

这条演示链路走下来大概15分钟，把系统的主要功能全部覆盖，而且每一步之间逻辑连贯，导师跟着你的节奏走，印象自然深刻。千万别把宝贵的时间浪费在去展示那些和技术不相关的花哨按钮上。

最后说点实在的

每次有人问我“毕设项目怎么才能做好”，我的回答都一模一样：不是代码写得有多炫，而是你有多清楚自己为什么这么写。Spring Boot二手滑板交易系统这个题目的好处是业务清晰、技术栈主流、颗粒度适中，它既不会简单到没东西可讲，也不会复杂到让你淹没在细节里。把状态机弄明白、把前后端联动的每一处边界处理好、把文档和自己的话术对齐，这个项目就是你毕业答辩和求职面试里都能拿得出手的硬通货。如果你现在正对着代码无从下手，建议从头把这篇文章提到的表和状态先理一遍，画完再动手，你会轻松很多。