高校二手交易这活儿我做了快三年了。最初是在实验室群里帮学弟学妹转发求购消息后来发现微信群和QQ群根本撑不起这件事消息刷得太快、没有结构化信息、交易全靠私聊、售后纠纷没人管。后来在学校创新项目里我用 SpringBoot 搭了一套校园二手物品交易平台系统从需求分析到数据库设计从前端页面到后端接口再到打包部署完整走了一遍。这套东西后来成了好多届课程设计和毕业设计的参考底子今天我把整个设计思路和实操过程拆开讲清楚希望能帮你少走弯路。这套系统并非什么炫技之作但胜在把“信息发布—浏览检索—在线交易—订单管理”这条业务闭环跑通了后端用 SpringBoot MyBatis-Plus前端用 Vue ElementUI数据库用 MySQL附带的源码、数据库脚本和万字设计文档都是可以直接落地修改的。无论你是要应付课程设计的阶段交付还是想把毕业设计做得有点含金量都值得把每一层设计逻辑搞明白——答辩时老师问的不只是“能不能跑”而是“为什么这么设计”。1. 内容整体设计与思路拆解1.1 高校二手交易的真实痛点为什么微信群收养不了闲鱼先说说我观察到的场景。每年毕业季宿舍楼下、校园墙上、各年级群里全是“出教材”“出售小电扇”“九成新自行车”这类消息。这些信息有几个问题第一时效性极强但无沉淀一条求购消息发出去几分钟就被新消息淹没第二没有统一信息结构商品描述全凭个人发挥价格、成色、交易方式说得含糊第三交易过程无保障私下转账、临时放鸽子、事后扯皮都很常见。学校其实需要一个“轻量级闲鱼”但闲鱼有自己的商品发布规范和信任体系校园场景又有其特殊性——交易双方多是同校学生更需要的是快、简单、能互相看到对方身份信息。我的设计目标是一个能承载完整商品信息、支持分类检索、自带订单流程和基础状态流转的 Web 系统让所有交易行为都可以被追踪减少口头约定带来的纠纷。这套系统选用的技术栈是 SpringBoot 2.x MyBatis-Plus MySQL 8.x前端使用 Vue 2 ElementUI 管理后台页面普通用户端则用 Thymeleaf 模板渲染兼顾开发效率和部署轻便性。说实话如果是课程设计纯后端加一个简单的模板引擎就能交付但为了展示全栈能力我把管理端也做成了前后端分离结构目的是让答辩演示时能有更多的页面亮点。1.2 为什么选 SpringBoot Vue一次选型背后的三年经验我不止一次被问过为什么不用 SSM 框架做为什么不用 JSP答案其实很简单——SpringBoot 把配置复杂度降到了最低。做课程设计的时间通常只有几周搭 SSM 时你得花时间整理各种 XML 配置、包扫描路径、数据源配置一个类名写错就要卡半天。SpringBoot 的自动配置和 starter 机制让项目初始化时间从一天压缩到十分钟。前端选 Vue 是因为组件化开发适合做表单、列表和状态切换尤其是商品发布页的“分类联动”和订单页的状态标签用 Vue 的指令和数据绑定会非常顺手。ElementUI 则提供了现成的表格、表单校验、弹窗组件避免手写一大堆 CSS。后端之所以用 MyBatis-Plus是因为它内置了单表 CRUD 的通用方法写业务代码时不用重复造轮子分页插件也省了很多事。对于毕业设计这种需要快速出成果的项目这是非常务实的选择。不过要注意技术选型也要考虑答辩深度。如果老师问“你用了什么缓存”“你怎么处理并发”你能拿出实际设计而不是机械地回答“用了 Redis”。我在项目中就加入了商品浏览量点击计数和简单的定时清理逻辑这比纯粹地说“我用了缓存”更有说服力。选型不是越复杂越好而是要好解释、好落地、好扩展。1.3 核心技术方案全景从分层架构到数据库设计这个系统的整体架构按经典的三层模式拆分Controller 层负责接收请求、参数校验和接口返回Service 层处理商品上架、审核、订单创建等核心业务逻辑Mapper 层通过 MyBatis-Plus 操作 MySQL 数据表。前端用户端与后端通过 RESTful API 对接管理后台通过 Vue 项目调用另一组接口普通用户访问时则使用服务端渲染的页面这样既保证了用户端的加载速度又降低了整体复杂度。数据库设计是这套系统最见功夫的地方。我设计了八张主要表用户表、商品分类表、商品表、商品图片表、订单表、购物车表、收藏表和管理员表。tb_goods表的设计尤为关键它必须包含商品标题、描述、价格、成色、校区位置、发布者ID、分类ID、状态字段在售、已下架、交易成功、举报中等。状态字段使用 tinyint 存储方便与前端状态标签做一一映射。数据库的每个字段都要有注释这是很多人容易忽略的地方。后期写设计文档、做答辩 PPT 时这些注释能极大地减少回忆成本。另外外键我一般不加物理外键只保留逻辑关联用索引去保证查询性能。这一点可能和教材上的范式要求有所不同但在实际项目中物理外键常常带来不必要的约束冲突逻辑外键配合 MyBatis-Plus 的关联查询反而是更常见的实践。2. 核心细节解析与实操要点2.1 数据库怎么设计才算“能用又不会过度设计”很多同学一上来就把表拆得特别细什么商品评价表、浏览历史表、消息通知表全都要。但我建议先分清主流程表和辅助表。主流程表是支撑核心功能的用户、分类、商品、订单、购物车。辅助表可以有但初期可以先用一个简单的字段表示比如收藏功能没时间做就可以先不做收藏表只做页面的收藏按钮等主体跑通了再补。毕业设计要的是完整闭环不是功能堆砌做得再花哨如果主流程跑不通也是白搭。拿商品表来说我的核心字段设计如下字段名类型说明idbigint主键自增user_idbigint发布者ID逻辑关联用户表category_idbigint分类ID关联分类表titlevarchar(100)商品标题descriptiontext商品描述闲鱼风格的详情pricedecimal(10,2)售价original_pricedecimal(10,2)原价用于显示折扣qualitytinyint成色99新/9成新/8成新/有瑕疵campus_locationvarchar(50)校区位置取货点statustinyint1-在售 2-已下架 3-交易成功 4-违规下架view_countint浏览次数点击加一create_timedatetime发布时间create_time我建议设置默认值CURRENT_TIMESTAMP更新时不必每次都写入省心。view_count是个小技巧虽然只是简单增一但它可以扩展出“热门商品”排序也是你答辩时能聊的一个功能点。分类表不需要做多级嵌套高校里的二手商品无非是“教材书籍”“数码电器”“生活用品”“运动户外”“其他”一级分类足够做个后台管理入口维护就可以了。再聊聊订单表。订单表字段包括 id、order_no订单编号、goods_id、buyer_id、seller_id、trade_price、status待付款、待发货、待收货、已成交、已取消、create_time、finish_time。注意订单表里要同时存买家ID和卖家ID而不是只存发布者ID。因为一个订单必然涉及两方查询“我买到的”和“我卖出的”时可以用同一个字段的两种情况去过滤用 SQL 查询时比较方便。订单编号我用时间戳加随机数生成避免表主键直接暴露业务量也方便后续对接物流。2.2 后端业务层的几个关键写法登录、发布、订单登录模块用 Session 保存用户状态前端把用户名和密码加密后发给后端后端用 BCrypt 对密码做哈希存储。之所以用 BCrypt 而不是简单的 MD5是因为彩虹表攻击很容易破解简单哈希而 BCrypt 自带随机盐能极大提高破解成本。这个细节在答辩时被问到的概率很高务必理解透彻。以用户注册为例核心代码如下Service public class UserServiceImpl implements UserService { Autowired private UserMapper userMapper; Override public Result register(UserRegisterDTO dto) { if (userMapper.selectByUsername(dto.getUsername()) ! null) { return Result.error(用户名已存在); } User user new User(); user.setUsername(dto.getUsername()); // BCrypt 加密不要存明文 user.setPassword(BCrypt.hashpw(dto.getPassword(), BCrypt.gensalt())); user.setPhone(dto.getPhone()); user.setCampus(dto.getCampus()); user.setStatus(1); user.setCreateTime(new Date()); userMapper.insert(user); return Result.success(); } }发布商品的逻辑要依次做几件事先校验用户是否登录然后获取当前登录用户的 ID再校验商品参数标题长度、价格范围、描述不能为空最后把图片信息循环写入商品图片表。关于图片上传我的方案是保存在服务器本地的upload目录并在配置文件中设置静态资源映射同时在商品表里存主图路径。这里有个坑如果后来把项目迁移到云服务器本地存储的图片路径可能会失效答辩时可以说“为了课程展示方便采用了本地存储后续可替换为 OSS”。这句话就能体现你的思考深度。订单创建的流程更值得仔细设计。当买家点击“立即购买”时最好做成“预下单”模式先生成订单状态为“待支付”然后跳转到订单详情页点击确认支付后再把状态改为“待发货”。如果直接在点击购买时就把商品状态改成“已售出”万一买家不支付商品就没法再卖了。我采用的做法是创建订单时只锁定商品不改变商品状态只有支付成功才把商品状态改为“交易成功”。同时要加一个定时任务超过 30 分钟未支付的订单自动取消商品恢复可售。这套逻辑在电商里很常见在课程设计里则是一个不小的加分点。2.3 前端与后端的协作约定从接口文档到联调前端对接时最怕的就是后端接口改来改去。我建议从项目初期就用统一返回格式Result比如{ code: 200, message: success, data: {} }。无论是单个对象、列表还是分页数据都封装到data字段里。前端通过code判断请求是否成功而不是依赖 HTTP 状态码。这样做的最大好处是后端即使抛异常也能通过Result.error(xxx)返回给前端一个可读提示前端弹窗直接展示就行。举个例子商品列表接口统一返回{ code: 200, message: ok, data: { total: 36, records: [ { id: 1, title: 高等数学第七版, price: 15.00, quality: 9成新, ... } ] } }前端拿到数据后直接渲染到 ElementUI 的el-table或卡片列表上。联调阶段要约定分页参数名为pageNum和pageSize排序字段放在orderByColumn。不要小看这些约定前端写死了参数名后后端一改前端就跨写。作为全栈开发者建议先定接口文档再用 Postman 测试前后端并行开发时才不会互相等。前端页面不要求精美但基础交互不能缺。商品列表要有搜索框和分类筛选商品详情页要有轮播图、商品基本信息、卖家信息、购买按钮和收藏按钮。发布商品页要能动态添加图片预览。我个人习惯用 Vue Router 管理页面跳转每个页面组件拆分清晰比如GoodsList.vue、GoodsDetail.vue、OrderList.vue这样后期维护时会轻松很多。3. 实操过程与核心环节实现3.1 从需求到交付完整开发流程与里程碑控制说实话很多同学做项目是先写代码再补文档这样不仅效率低而且容易返工。我的建议是先花两天做需求梳理和原型设计再用两天建数据库和核心接口然后花一周迭代前后端留出三天测试和写文档。整体节奏是“先慢后快”前期需求清楚了后期代码反而写得快。第一步是梳理角色权限。系统里有三种角色普通用户、管理员和游客。游客只能浏览商品登录用户可以发布、购买、收藏、管理自己的商品和订单管理员可以审核商品、管理分类、封禁用户。角色划分清晰后整个系统的菜单和操作就自然出来了。页面上游客访问受限功能时统一提示“请先登录”并跳转到登录页这是最省事的权限控制办法。第二步是画页面原型。我用的工具是墨刀或手绘草图不用太精细但要标清楚每个页面的按钮、跳转、表单字段。比如商品发布页的字段是分类、标题、描述、价格、原价、成色、取货地点、图片。原型阶段就能发现字段缺失或不合理的地方比如忘了加“校区位置”会导致后续交易时不知道去哪里取货。这个字段就是我在原型阶段补上去的。第三步是创建 SpringBoot 项目。直接用 Spring Initializr 生成基础工程依赖选上spring-boot-starter-web、mybatis-plus-boot-starter、mysql-connector-java、lombok、spring-boot-starter-validation。配置application.yml里的数据源和 MyBatis-Plus 相关配置例如server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/campus_secondhand?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: 123456 servlet: multipart: max-file-size: 10MB max-request-size: 30MB mybatis-plus: configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl global-config: db-config: id-type: auto这里有个细节map-underscore-to-camel-case一定要设为true这样才能把数据库的campus_location自动映射到 Java 的campusLocation属性避免手动写一堆TableField。serverTimezone必须指定否则高版本 MySQL 驱动连接时会报时区错误。3.2 核心模块逐行拆解从用户登录到交易闭环按这个流程我先实现用户模块。登录接口应该是/api/user/login接收用户名和密码认证通过后在 Session 中保存userId。后续所有需要登录的操作都从HttpSession里拿userId。需要注意Session 的 key 建议定义为常量比如LOGIN_USER_ID不要硬编码字符串散落在代码里。商品发布模块我放在/api/goods/publish入参是一个描述商品的 DTO 类。用 Spring 的Validated做参数校验例如标题NotBlank(message 标题不能为空)价格NotNull(message 价格不能为空)。校验失败时后端自动返回参数错误前端提示具体原因。这样比自己在 Controller 里写 if 判断要规范得多。商品列表查询用 MyBatis-Plus 的分页插件核心代码public PageGoodsVO queryGoodsPage(GoodsQueryDTO dto) { LambdaQueryWrapperGoods wrapper new LambdaQueryWrapper(); wrapper.eq(Goods::getStatus, 1); // 只查在售 if (StringUtils.isNotBlank(dto.getKeyword())) { wrapper.and(w - w.like(Goods::getTitle, dto.getKeyword()) .or().like(Goods::getDescription, dto.getKeyword())); } if (dto.getCategoryId() ! null) { wrapper.eq(Goods::getCategoryId, dto.getCategoryId()); } wrapper.orderByDesc(Goods::getCreateTime); PageGoods page goodsMapper.selectPage(new Page(dto.getPageNum(), dto.getPageSize()), wrapper); // 还要把 categoryName、sellerNickname 等关联字段填充到 VO 中返回 }这里我习惯把结果转成 VO 对象前端需要什么就返回什么避免直接把数据库实体的所有字段都暴露出去。比如商品表里有description字段列表接口只返回摘要详情接口才返回全文。这一步能减少网络传输量也让前端代码更干净。订单模块的另一个核心是状态机设计。我维护一个订单状态枚举0-待付款、1-待发货、2-待收货、3-已成交、4-已取消。状态流转有严格限制比如“已成交”只能由“待收货”变过来不能在“待付款”状态下直接改成“已成交”。我在每个状态变更方法里都加上当前状态判断如果状态不对就抛出异常。这样做的好处是防止多人并发操作时订单状态出现错乱。购物车模块也很简单加入购物车时检查商品是否在售、是否自己的商品如果已经在购物车中则只修改数量。结算时选中多条商品生成多个订单但要注意商品库存或状态可能发生变化所以结算前要重新校验每个商品的当前状态。这个过程虽然简单但如果忽略就会出现“商品已被别人买走但购物车里还能结算”的 bug。3.3 部署上线从本地打包到服务器运行本机跑通后部署也算一个完整环节。SpringBoot 项目可以打成 jar 包用java -jar命令运行。打包前需要修改配置把数据源地址改为服务器数据库的地址并且把上传图片的目录改为服务器上的绝对路径。前后端分离时Vue 项目先执行npm run build把生成的dist目录交给 Nginx 托管再通过 Nginx 反向代理转发/api请求到后端 8080 端口。我给出一个常用的 Nginx 配置片断server { listen 80; server_name your.domain.com; location / { root /usr/share/nginx/html; index index.html; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }这里try_files处理 Vue Router 的 history 模式非常关键否则刷新页面会 404。后端接口统一带/api前缀这样 Nginx 只需要按路径转发。部署之后需要验证几个关键路径首页能否正常访问、登录后能否发布商品、图片能否正常显示、订单流程能否跑通。我通常会先跑一遍核心流程再开放给同学试用避免演示时掉链子。4. 常见问题与排查技巧实录4.1 高频问题清单与排查路径做这个项目时下面几个问题我几乎每次都会遇到也是学生来找我问得最多的第一端口被占用。启动时提示Port 8080 was already in use解决方法是改端口或者杀掉占用进程。但更常见的场景是被自己电脑上的其他服务占用了比如之前写某个项目时开过 Nginx 或 Tomcat。用netstat -ano | findstr 8080找到 PID然后taskkill /PID xxx /F即可。第二数据库连接失败。报错Access denied for user rootlocalhost或者Communications link failure。前者检查用户名密码后者检查 MySQL 服务是否启动以及连接 URL 是否正确。还有一个经常被忽略的问题MySQL 8.x 的驱动类名是com.mysql.cj.jdbc.Driver如果不小心写成旧的com.mysql.jdbc.Driver会直接连接失败。第三前端跨域。前后端分离时如果前端跑在 8080 端口而项目本身在 8080或者前端跑在 8081浏览器可能会报跨域错误。我给后端配置一个CorsFilter放行本地开发地址同时生产环境复用 Nginx 反向代理从而避免跨域。第四MyBatis-Plus 查询不到数据。多半是因为数据库字段与实体属性映射不上。我加map-underscore-to-camel-case: true后基本能解决。另外如果实体类加了TableId(type IdType.ASSIGN_ID)而数据库主键不是雪花 ID 而是自增也会出现插入数据后主键为空的情况建议统一用IdType.AUTO。4.2 如何从课程设计升级为可展示的毕业设计课程设计的交付标准和毕业设计还是有差距的。如果你只是按课程要求做一个能跑通的 demo那么分页、搜索、下单功能齐全就够了。但毕业设计需要的是系统性思考我建议在原有基础上补三块东西第一块是全局异常处理。用RestControllerAdvice统一捕获业务异常和系统异常返回给前端的永远是友好的 JSON 提示而不是一堆堆栈信息。这不仅是代码规范问题更是体现工程素养的地方。第二块是操作日志。记录用户的登录、发布、购买等关键操作存到日志表或文件中。答辩时可以展示“我通过日志审计来追踪恶意操作”这是一个很实际的加分项。第三块是测试用例。不需要写很多但至少覆盖登录、商品发布、下单流程的单元测试或接口测试。我常用 Postman 做完接口自测后再用 JUnit 写几个核心 Service 层的测试用例。老师看到你的测试类印象分会提升不少。4.3 源码、数据库和万字文档的配套使用建议最后聊聊你拿到的这套源码和文档应该怎么用。我见过太多同学直接把源码导入 IDEA然后因为环境不对跑不起来就放弃了。正确的打开方式是先把doc目录里的数据库脚本在 MySQL 里执行建好库和表然后打开application.yml改成自己本机的数据库账号密码再用 IDEA 打开后端工程等 Maven 依赖下载完毕启动主类。前端项目如果有的话先npm install再npm run serve打开页面就能看到效果了。数据库脚本我会提供测试数据大约二十几条商品信息覆盖多个分类和不同成色方便你直接演示列表、搜索和详情页。这种“开箱即用”的设定能大幅减少前期部署成本。万字设计文档也不是让你直接交上去的最好是先通读一遍对照文档里的功能描述操作一遍系统再根据自己的需求改动。比如想增加“微信小程序端”或者“支付接口模拟”那就在文档里相应章节做扩展设计。答辩时如果老师问你“这个优化是你做的吗”你至少能讲清楚改动了哪个表、哪个接口而不是一脸茫然。从我做完这个项目到现在已经用它帮过不少人。每次看到别人跑通系统后露出那种“原来是这么一回事”的表情我都觉得这比单纯写代码更有成就感。最后分享一个小技巧不管技术选型多简单一定要把核心流程的时序图画进文档里——商品从发布到成交经历了哪些状态变化为什么订单要经历待付款、待发货、待收货这些环节。把这张图画明白了答辩时你基本就稳了。