前阵子带人做项目选型二手物品交易系统又成了热门选项。这个题目的好处在于需求场景清晰、功能边界明确、前后端都有足够空间施展而且做出来的东西确实能跑、能演示、能答辩。最近我把一套基于SpringBootVue的二手物品交易管理系统完整跑通了一遍后端工程代号叫bootpf顺手把整个设计和实现过程梳理成了这篇文章。我不是来发代码包的而是要把从需求拆解、数据库建模到前后端联调这一路的真实思路和踩坑记录写清楚。技术栈就是标题里那套JavaMySQLMyBatis做后端Vue做前端。如果你正在纠结毕设选题或者想找一个完整的全栈项目练手这篇文章应该能帮你少走不少弯路。1. 这个二手交易系统的需求到底长什么样很多人拿到这类题目第一反应是不就是个商品增删改查吗真做起来才发现二手交易和普通商城在需求上有本质区别。先把这个理清楚后面写代码才不会返工。1.1 角色与权限谁在使用这个平台一套完整的二手交易系统至少要有两类使用者普通用户和管理员。这里的普通用户既是买家也是卖家——这是二手平台和B2C商城的核心差异任何一个注册用户都应该能在买东西和卖东西两个身份之间自由切换。普通用户端的需求拆开看大概是这些功能模块具体说明注册登录用户名、密码、手机号、昵称等基础信息密码加密存储商品浏览首页商品流、分类筛选、关键字搜索、商品详情查看商品发布填写标题、描述、价格、成色、分类上传图片我的商品查看自己发布的商品支持编辑、上下架操作收藏管理收藏感兴趣的商品在我的收藏里快速找到留言咨询对商品发起提问卖家查看并回复订单管理下单、发货、确认收货、取消订单评价交易完成后互评影响买卖双方信用管理端则是另一套逻辑功能模块具体说明用户管理用户列表禁用/解禁违规账号商品管理商品列表下架违规商品推荐/取消推荐分类管理维护商品分类树增删改分类订单管理查看所有订单处理纠纷/异常订单数据概览用户数、商品数、交易量等基础统计权限控制这块实际做的时候不需要引入Spring Security那么重的东西。在user表里加一个role字段用0和1区分普通用户和管理员后端写一个简单的拦截器判断接口权限前端再根据角色渲染不同菜单完全够用。过度设计在毕设和练手项目里是大忌。1.2 核心业务流程从发布到成交的完整闭环业务流程是这套系统的灵魂。我在设计阶段画过完整的状态流转图这里用文字把关键链路说清楚。商品发布链路用户登录后填写商品信息提交后进入待上架状态管理员在后台审核通过后商品变为上架状态出现在前台商品列表中。对于练手项目如果不想做审核环节也可以省掉审核状态发布即上架但答辩时老师一定会问怎么处理违规商品所以留一个下架接口管理端能操作即可。二手商品和一手商品在发布时的字段差异也要注意成色、入手渠道、入手价格、转手原因这些是二手场景特有的信息。尤其是成色直接决定买家心理预期是二手交易里最重要的一个卖点。交易链路买家看中商品后可以对卖家发起留言咨询确认没问题后下单。下单后订单状态变成待付款系统这里用模拟支付按钮替代真实支付支付后变成待发货卖家那边看到订单后操作发货变成待收货买家确认收货后变成已完成。完成之后买卖双方可以互相评价整个交易闭环才算真正走完。这里有个设计细节值得说一下就是商品和订单是解耦的。订单表里除了商品ID还要冗余一份商品快照标题、图片、价格因为订单是交易凭证如果卖家把商品改了或删了订单里的信息不能跟着变。这个细节做数据库设计的时候非常能体现思考深度。2. 为什么是SpringBootVueMyBatis这套组合技术选型不是越新越好而是越适合越好。这套组合放在二手交易系统上属于典型的不折腾且能讲清楚道理的方案。2.1 后端选型SpringBoot省下的配置功夫如果是早几年用SpringMVC光是配置文件就够写半天的web.xml、spring.xml、spring-mvc.xml、数据源配置、事务配置每一处都是坑。SpringBoot把这些统一收敛成自动配置和starter依赖一个application.yml就搞定大部分事情。内嵌的Tomcat让部署也简单了后端打包成jar直接java -jar就能跑。SpringBoot在二手交易系统里帮我们处理了大量基础设施问题spring-boot-starter-web帮我们搭好了MVC和JSON序列化spring-boot-starter-jdbc和数据源配合数据库连接配置控制在配置文件里事务支持通过Transactional注解就能实现对订单这类强一致性的业务非常关键内置的拦截器、过滤器机制方便做登录校验这个项目的artifactId我当时起的就是bootpf就是Boot Platform的意思纯粹内部工程代号没有其他含义。后面前端工程对应叫bootpf-web方便一眼看出两个工程的归属。2.2 前端选型Vue组件化在二手交易场景的契合点Vue这套前端框架之所以适合这个场景核心在于组件化和响应式数据。二手交易系统的前台有大量重复出现的东西商品卡片、分类导航、分页器、搜索框每个页面都在复用同样的UI和逻辑。Vue把每个部分封装成组件之后商品列表可以复用商品卡片组件我的收藏页面也可以复用同一个组件代码量肉眼可见地减少。响应式数据绑定对搜索筛选也格外好使。带上价格区间、选择分类、输入关键词这些筛选条件用data属性绑着数据一变页面自动更新不需要像JQuery时代那样手动操作DOM。联调的时候前后端分工也清晰后端只返回JSON数据前端负责渲染。项目里我用的Vue版本是Vue2配ElementUI这个组合文档多、坑少、资料遍地都是对新手最友好。如果你对Vue3和Element Plus更熟直接用Vue3也没问题骨架思路完全一致。2.3 MyBatisMySQL轻量ORM和动态SQL的默契配合后端选型时很多人会纠结MyBatis和JPAHibernate选哪个。我的建议很直接查询条件复杂的业务系统无脑选MyBatis。二手交易系统的商品列表查询就是个典型的多条件动态查询。用户可能按分类查可能按价格区间查可能按成色查也可能同时输入好几个条件还可能要按时间排序。这种查询条件个数不确定的场景恰恰是MyBatis动态SQL最擅长的地方。在XML里用if标签拼条件有就拼接没有就跳过一条SQL可以应对无数种查询组合。换成JPA的话要么用规格类那套抽象要么一个条件写一个方法写起来绕且不直观。MySQL作为底层数据库没什么悬念开源免费、主流稳定、资料丰富最重要的是事务和锁机制足够支撑订单这种核心业务。MySQL8的JSON字段类型还可以用来存商品图片列表不过这个需求用普通字符串处理更简单没那么玄乎。3. 数据库设计与表结构拆解数据库设计决定了这套系统的天花板。表设计好后面写代码如鱼得水表设计烂后面每个接口都在填坑。我把这个项目的主要表按模块拆开讲。3.1 用户与分类基础表的细节不能省用户表是系统的基础字段设计要兼顾登录、展示和权限字段名类型说明idBIGINT主键自增usernameVARCHAR(50)登录用户名唯一索引passwordVARCHAR(100)密码MD5加盐或BCrypt加密后存储nicknameVARCHAR(50)昵称前端展示用avatarVARCHAR(200)头像图片路径phoneVARCHAR(20)手机号roleTINYINT0普通用户1管理员statusTINYINT0正常1禁用create_timeDATETIME注册时间密码加密这件事必须重视。明文存密码是答辩现场最容易被致命追问的硬伤也是实际开发中的最低级错误。我习惯用MD5加盐的思路演示加盐的意思是在原始密码后面拼一段随机字符串再做哈希这样即使两个用户密码相同存出来的哈希值也不一样。加密后数据库里就算被盗也不会直接泄漏原始密码。分类表用自关联的形式支持多级分类。一级分类像数码产品服饰日用图书教材二级分类是具体品类如手机电脑女装。用parent_id字段指向父分类ID顶级分类的parent_id为0这样一个表就能撑起三级甚至更多级的分类树。3.2 商品表二手商品的字段比你想的多商品表是整个系统的核心表。我在设计时往里面塞了很多二手专属字段这也是和普通商城商品表最明显的区别字段名类型说明idBIGINT主键seller_idBIGINT卖家ID外键关联用户表category_idBIGINT分类IDtitleVARCHAR(100)商品标题descriptionTEXT商品详细描述original_priceDECIMAL(10,2)入手原价current_priceDECIMAL(10,2)当前转让价condition_levelTINYINT成色1全新 2九成新 3八成新 4七成新及以下imagesVARCHAR(1000)图片路径集合用逗号分隔statusTINYINT0草稿 1上架 2下架 3已售出views_countINT浏览量create_timeDATETIME发布时间update_timeDATETIME更新时间这里说几个设计时的关键判断。第一原价和现价必须分开。二手商品的价值感来源之一就是比原价便宜多少商品详情页要把原价用删除线划掉现价加粗展示这种视觉对比能明显增强购买欲望。只放一个价格字段这个卖点就丢了。第二成色等级不能做成自由文本。让用户自己输入很新几乎没怎么用过这种描述前端筛选就完全没法处理。用数字枚举锁定成色等级既方便前端做筛选下拉框也能让列表页按成色排序。第三图片字段用逗号分隔路径存还是单独建一张图片表项目规模不大时逗号分隔足够用。Java后端接收上传后返回路径列表前端用split方法拆开渲染成轮播图即可。一个字段解决的事情没必要再建一张表增加JOIN复杂度。第四status字段是商品状态的核心。设计的精髓在于它和订单状态联动——商品一旦被人下单进入已售出状态就不能被搜到、不能被重复下单。什么时候恢复成上架订单取消的时候。这个联动的逻辑后面会细讲。3.3 订单与评价交易闭环的两张核心表订单表的字段设计直奔交易凭证这个定位字段名类型说明idBIGINT主键order_noVARCHAR(32)订单号业务唯一product_idBIGINT商品IDproduct_titleVARCHAR(100)商品标题快照product_imageVARCHAR(200)商品图片快照product_priceDECIMAL(10,2)成交价快照buyer_idBIGINT买家IDseller_idBIGINT卖家IDstatusTINYINT0待付款 1待发货 2待收货 3已完成 4已取消create_timeDATETIME下单时间pay_timeDATETIME付款时间deliver_timeDATETIME发货时间finish_timeDATETIME完成时间订单号order_no的生成策略我推荐用时间戳随机数或年月日时分秒用户ID截取的方式核心诉求只有一个不重复。纯自增ID不适合直接暴露给用户当订单号一是太长二是容易被猜到单量。金额字段用DECIMAL(10,2)是原则性问题。float和double在计算机里的二进制存储天生有精度问题0.1加0.2可能等于0.30000000000000004涉及钱的运算出现了这种结果整单逻辑都别想正确。DECIMAL是定点数在数据库层面就保证了精度。订单状态字段看起来很常规实际上就是一张状态机的表待付款买家下单成功此时商品锁定为已售出待发货买家模拟支付完成需要卖家发货待收货卖家已发货等待买家确认已完成买家确认收货订单完结触发评价入口已取消超时未付款或任意一方取消商品恢复上架评价表我坚持要求每个订单最多一条评价。实现方式是在评价表里给order_id加唯一约束数据库层面的约束比代码层面的if判断可靠得多。评价的rating字段用TINYINT存1到5星content存文字评价mutual表示这份评价是买家给卖家的还是卖家给买家的。4. 后端接口与核心业务逻辑实现表设计完了后端接口的开发就顺理成章分层套路固定Controller接收请求、Service处理业务、Mapper负责数据库操作。但有几个核心逻辑值得单独拉出来讲清楚因为这些地方最容易出问题也最能体现一个开发者靠不靠谱。4.1 登录鉴权Session还是JWT登录鉴权方案的选择直接影响后面所有接口的写法。我见过太多人一上来就选JWT结果token刷新、过期处理、服务端主动失效这些额外问题一堆把整个方案的复杂度推高了一大截。对于一个单体架构、无前后端分离部署压力的教务/毕设级别项目Session方案其实更实用。对比维度Session CookieJWT服务端存储需要存session不需要实现复杂度低中服务端主动失效方便销毁session困难需维护黑名单前后端分离可行需配代理天然友好适合场景单体应用分布式/微服务我当时实际选择的是Session方案登录成功后把用户ID和role放进Session写一个拦截器把需要登录的接口拦下来校验Session里有没有用户没有就返回401。管理员接口额外检查role是不是1。整个鉴权逻辑加起来不到100行代码。如果是前后端完全分离、部署在不同域名下的场景Session方案确实会遇到跨域Cookie问题这时候转JWT更顺。我在文章后半段会讲前端的配合处理。如果你老师要求用JWT就去用Token加拦截器的方式设计思路上殊途同归。4.2 商品模块接口分页、搜索与上下架商品模块的接口设计走RESPful思路路径和语义保持一致GET /api/product/page —— 分页多条件查询商品GET /api/product/{id} —— 商品详情POST /api/product —— 发布商品PUT /api/product/{id} —— 编辑商品PUT /api/product/{id}/status —— 上下架商品DELETE /api/product/{id} —— 删除商品逻辑删除分页查询是商品列表的核心接口。我习惯手写分页而不是用PageHelper插件原因很简单手写LIMIT语句逻辑清清楚楚PageHelper偶尔会遇到版本不兼容导致的分页失效问题排查起来反而浪费时间。分页参数就两个pageNum和pageSize后端计算出offset传给SQL。多条件动态查询这一段是MyBatis动态SQL最能展示价值的地方select idselectProductPage resultTypecom.bootpf.entity.Product SELECT * FROM product where status 1 if testkeyword ! null and keyword ! AND title LIKE CONCAT(%, #{keyword}, %) /if if testcategoryId ! null AND category_id #{categoryId} /if if testminPrice ! null AND current_price gt; #{minPrice} /if if testmaxPrice ! null AND current_price lt; #{maxPrice} /if if testconditionLevel ! null AND condition_level #{conditionLevel} /if /where ORDER BY create_time DESC LIMIT #{offset}, #{pageSize} /select这个写法的妙处在于用户传了几个条件SQL就只有几个条件不传的条件自动忽略。所有筛选条件都在同一个接口里处理前端不需要按条件拆多个接口。keyword的模糊搜索用LIKE加上百分号拼接二手交易系统的搜索不需要全文搜索引擎这个量级完全够用。文件上传用Spring Boot自带的MultipartFile就能实现。我写完上传逻辑后图片存在本地上传目录数据库只存相对路径前端通过静态资源映射访问。配置里记得调大文件大小限制不然传几张稍大的图就报错spring: servlet: multipart: max-file-size: 10MB max-request-size: 50MB mvc: static-path-pattern: /upload/** resources: static-locations: file:D:/bootpf/upload/静态资源路径配置这里容易踩坑如果不加static-locations配置前端访问图片路径时会得到404。这个报错几乎每个做文件上传功能的人都会遇到一次属于必修课。4.3 订单创建的事务与并发最容易翻车的地方创建订单是整个系统业务逻辑最密集的接口也是最容易翻车的地方。很多人第一版写出来的逻辑是插入订单记录、修改商品状态、扣减库存三个步骤三个方法但没有加事务。结果订单插入成功、商品状态更新失败买家以为自己下单了卖家那边商品却还是上架状态最终出现一单两卖的情况。创建订单的逻辑必须用Transactional包住要么全部成功要么全部回滚Transactional(rollbackFor Exception.class) public Order createOrder(Long productId, Long buyerId) { Product product productMapper.selectById(productId); if (product null || product.getStatus() ! 1) { throw new BizException(商品不存在或已下架); } // 乐观锁更新只有status1时才能更新为已售出 int rows productMapper.updateStatus(productId, 3, 1); if (rows 0) { throw new BizException(手慢了商品已被购买); } Order order new Order(); order.setOrderNo(generateOrderNo()); order.setProductId(productId); order.setProductTitle(product.getTitle()); order.setProductImage(product.getImages()); order.setProductPrice(product.getCurrentPrice()); order.setBuyerId(buyerId); order.setSellerId(product.getSellerId()); order.setStatus(0); order.setCreateTime(new Date()); orderMapper.insert(order); return order; }这里的核心是那一行WHERE status 1的UPDATE。它叫做乐观锁思路更新的时候加上条件判断数据库的锁机制会保证同一时刻只有一个事务能更新成功第二个事务来更新时发现status已经不是1了受影响行数为0于是抛出手慢了商品已被购买。这种方式既防止了超卖又不需要手写synchronized或Redis分布式锁在这个并发量级的系统中足够可靠。订单取消的逻辑同样要注意事务订单状态改成已取消的同时商品状态要改回上架。只改一边不动另一边就会造成商品明明没卖出却无法被搜索到的尴尬场景。5. 前端Vue页面组织与前后端联调的实战细节后端接口写完后前端的工作量大头其实不在写页面而在怎么把页面组织和数据请求理清楚。很多项目死在了联调阶段尤其是跨域和请求拦截这两个点。5.1 页面路由与组件拆分前端工程的结构我分成views和components两个主要目录。views放页面级组件每个路由对应一个components放可复用的通用组件。页面路由表大概是这样的路径页面说明/home首页商品流、分类导航、搜索栏/product/detail/:id商品详情图片轮播、信息展示、下单入口/publish发布商品表单页含图片上传/user/products我的商品管理自己发布的商品/user/orders我的订单按角色区分买家/卖家维度/user/favorites我的收藏收藏列表/user/profile个人中心基本信息修改/admin管理后台用户/商品/分类/订单管理/login /register登录注册独立页面商品卡片是复用度最高的组件列表页、收藏页、我的商品页全都在用它。组件内部接收一个product对象渲染封面图、标题、价格、成色角标点击跳转详情页。这种一个组件多个页面复用的组织方式是Vue组件化思想最落地的地方。详情页的下单按钮要区分情况商品是自己发布的不能买成色和原价展示在前面提到的二手专属字段上。这些逻辑放在前端判断只是体验层最终的正确性由后端接口保证前端判断只能作为辅助。5.2 axios封装与统一错误处理项目里的所有请求都走封装好的request.js不要让每个页面都直接去axios.get。封装axios的核心目的是统一处理baseURL、token注入、错误码响应和登录失效跳转import axios from axios const request axios.create({ baseURL: /api, timeout: 10000 }) // 请求拦截器把登录用户的会话信息带上 request.interceptors.request.use(config { const user sessionStorage.getItem(user) if (user) { config.headers[Authorization] Bearer user } return config }) // 响应拦截器统一处理后端返回的业务码 request.interceptors.response.use( response { const res response.data if (res.code ! 200) { this.$Message.error(res.msg) if (res.code 401) { router.push(/login) } return Promise.reject(new Error(res.msg)) } return res.data }, error { this.$Message.error(网络异常请稍后重试) return Promise.reject(error) } ) export default request这样封装完之后每个页面的请求代码就只剩下一句话request.get(/product/page, { params })。统一拦截的好处是全局逻辑只写一次。比如登录失效的情况下前端自动跳回登录页而不是每个接口都写一遍重复的判断。5.3 跨域与静态资源的处理方案前后端联调时最经典的报错就是跨域。后端跑在8080端口前端开发服务器跑在8081端口前端请求后端接口如果不处理浏览器会直接拦截。这里有几种标准方案按场景选方案适用场景配置复杂度后端CorsFilter任意场景低前端devServer代理开发环境低Nginx反向代理生产环境中我在开发时用vue.config.js的代理方式把前端请求的/api前缀转发到后端8080端口浏览器视角里所有请求都是同源跨域问题直接消失module.exports { devServer: { proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } }这里有一个细节陷阱后端的Controller如果没加统一前缀代理转发后路径很容易对不上。优雅的做法是后端Controller统一带/api前缀和前端代理路径完全对齐避免手忙脚乱地改路径。后端如果选择Session方案前端用axios请求时会自动携带Cookie吗代理模式下同源Cookie自动带上Session机制正常工作。如果你选了JWT方案请求头里手动带token即可不存在Cookie跨域问题。两个方案和前端代理的配合都验证过是稳定的。6. 源码导读从零跑通项目与二次扩展建议拿到一套完整源码后很多人的第一个困惑是从哪看起。我按自己的阅读习惯和调试经验把一套SpringBootVue项目的阅读路径和运行细节整理出来至少能在拿到源码的第一小时做到不慌。6.1 后端目录结构拿到源码先看哪里一个规范的SpringBoot后端工程目录结构是这样的bootpf ├── pom.xml ├── src/main/java/com/bootpf │ ├── BootpfApplication.java // 启动类 │ ├── controller/ // 接口层 │ │ ├── UserController.java │ │ ├── ProductController.java │ │ ├── OrderController.java │ │ └── AdminController.java │ ├── service/ // 业务逻辑层 │ │ ├── UserService.java │ │ ├── ProductService.java │ │ └── OrderService.java │ ├── mapper/ // 数据访问层 │ │ ├── UserMapper.java │ │ ├── ProductMapper.java │ │ └── OrderMapper.java │ ├── entity/ // 实体类对应数据库表 │ │ ├── User.java │ │ ├── Product.java │ │ └── Order.java │ ├── config/ // 配置类 │ │ └── WebConfig.java │ └── common/ // 通用工具 │ ├── Result.java // 统一返回封装 │ ├── BizException.java // 自定义业务异常 │ └── GlobalExceptionHandler.java阅读源码的顺序我建议先看entity里有哪些实体对应数据库哪几张表再看controller了解系统暴露了哪些接口然后看service里的核心业务方法特别是带Transactional的最后再看mapper里的XML文件怎么写的SQL。控制器服务Mapper的调用链是SpringBoot后端的主线顺着这条线读下来整个系统的骨架就清楚了。统一返回封装Result是我每套系统都坚持做的。所有接口都返回{code, msg, data}这个结构前端axios响应拦截器才能统一处理错误。如果不做这层封装会出现每个接口返回格式都不一样前端越改越乱的局面。6.2 本地运行配置与常见坑拿到源码第一件事是把项目跑起来。后端运行步骤创建数据库执行项目里的bootpf.sql脚本初始化表和测试数据修改application.yml里的数据库账号密码IDEA导入maven工程等待依赖下载完成运行BootpfApplication.java后端默认8080端口打开swagger或直接访问接口文档地址验证前端运行步骤进入bootpf-web目录npm install安装依赖npm run serve启动开发服务器默认8081端口浏览器访问前端地址跑起来的过程中有四个高频报错几乎每个人都会遇到报错信息原因解决方案Access denied for user数据库账号密码错误检查application.ymlUnknown time zone数据库时区未配置连接串加serverTimezoneAsia/ShanghaiPort 8080 already in use端口被占用改后端端口或kill占用进程Failed to read candidate component class依赖没下载mvn clean 重新导入前端图片404静态资源映射没配检查yaml里的static-locations配置这些坑全部是基于我实际操作经验的总结每个都真实翻过车。尤其是时区问题MySQL8默认使用UTC时区和本地时间差了8个小时不配置时区后端会直接报错这个问题几乎成了MySQL8新手的固定拦路虎。6.3 从毕设到实际应用的扩展思路一个拿得出手的系统能跑通主流程只是及格线。如果你还想让这个项目在答辩或者简历上更有竞争力这里有四条切实可行的进阶方向。第一接入Redis做缓存。商品详情页是热点数据用户每次刷新都要查数据库量大了扛不住。把浏览量高的商品缓存到Redis设置过期时间能显著降低数据库压力。这属于成本低、故事好讲的加分项。第二用WebSocket做站内消息通知。买家下单后通过WebSocket实时通知卖家你有新订单卖家发货后买家收到通知。这个功能能让系统的实时体验上一个台阶实现复杂度又不算太高。第三给商品加一个猜你喜欢的推荐逻辑。基于用户收藏和浏览记录查询同分类其他商品推荐展示。不需要搞算法简单的看过的人都看过SQL查询就能实现讲起来也有说服力。第四引入RabbitMQ做订单超时自动关闭。模拟支付的订单如果30分钟未付款通过延时队列自动取消并恢复库存。这个方案可以把订单状态机的已取消分支补完整也展示了消息队列的实际应用场景。这些扩展方向做任何一个都能给项目增加差异化亮点而且我建议只挑一个做透做精比堆砌三个半成品要好。最后分享一点个人体会这套SpringBootVue二手交易系统我前后带项目跑了不止五遍每一遍都会发现新的优化点。如果你正在拿这套源码做自己的项目我的建议是先老老实实把主流程跑通从数据库脚本执行到下单、发货、收货完整走一遍之后再考虑锦上添花的功能。项目里的代码注释和调试记录都很完整对着代码动手改一改琢磨一下每个接口为什么要这么设计收获比拿着浏览器刷十篇技术文章都大。