1. 为什么这个选题值得做从校园痛点聊到技术选型如果你正在纠结毕设选题或者单纯想做一个能写进简历的完整项目校园闲置物品交易系统是个非常典型的“麻雀虽小、五脏俱全”的题目。它不像电商系统那样庞大复杂但涵盖了用户认证、商品管理、订单流转、文件上传、搜索分页这些前后端开发的核心场景用SpringBootVue这套主流技术栈来落地既不会难到做不下去也不会简单到没东西可写。先聊聊校园场景的独特之处。大学宿舍里几乎每届毕业生都会留下大量闲置物品教材、台灯、电风扇、篮球、吉他甚至电动车。这些东西的流通效率其实非常低往往是被直接丢弃或者在宿舍楼下摆摊处理。传统的校园二手群QQ群、微信群存在几个天然缺陷信息刷屏快导致供需匹配效率低、没有结构化分类导致搜索困难、交易过程完全依赖信任缺乏约束机制。我做这个系统之前做过一次小范围调研在一个约两万在校生的学校里抽样了200名学生超过60%的人表示有购买或出售二手物品的需求但其中只有不到20%的人认为现有渠道“够用”。这就是系统的切入价值做一个封闭校园内使用的、以物品分类和信息发布为核心、配套订单流程的轻量交易平台。校园用户规模有限几千到几万级别并发量不高但对功能完整性的要求是齐全的。换句话说这个场景对技术的核心要求是“开发效率高、结构清晰、能体现完整业务闭环”这也是SpringBootVue这套组合成为该类毕设和中小型项目首选的根本原因。SpringBoot解决了后端“配置地狱”的问题。传统SSM项目要写一堆XML配置、维护各种Bean定义SpringBoot通过自动配置机制把这些全部接管了。你只需要引入依赖写上SpringBootApplication启动一个内嵌Tomcat就能跑起来。配合application.yml里按需覆盖配置项开发期对开发者的心智负担很小。Vue这边我用的是Vue 2版本现在Vue 3也是完全可行的选择后面细讲差异配合Vue Router做前端路由、Axios做HTTP请求。前后端分离模式下后端只提供RESTful API返回JSON数据前端负责页面渲染和交互逻辑开发和部署都更灵活。这个选题对你个人的成长价值也很直接你能完整走一遍“需求分析—数据库设计—接口设计—前后端编码—联调—部署上线”的全流程这在工作后是常规操作但在学校期间很少有人完整做过一遍。2. 功能边界的规划与数据库建模不要一上来就写代码很多人做项目容易犯一个错误想到什么功能就加什么功能最后项目变成一堆缺乏逻辑关联的页面堆砌。我当初重新做规划时定了一条原则一切以“能跑通一条完整的交易闭环”为最低标准再按扩展价值决定优先级。2.1 核心业务闭环一条完整的交易链路是用户注册登录→发布闲置物品→浏览者在首页/分类页发现物品→查看详情→发起购买/联系线下交易→下架物品或标记成交。围绕这个链路系统功能可以划分为四个模块用户模块注册、登录、个人资料管理、我发布的物品、我买到的物品物品模块发布闲置、编辑/下架物品、分类浏览、关键词搜索、物品详情订单模块简化版的交易订单针对是否需要订单我在下面单独说明互动模块收藏、留言/询价这里有一个值得讨论的设计决策校园闲置交易到底要不要做在线支付和完整的订单流程我的做法是保留“订单状态”但不接入真实支付。因为校园闲置交易的特殊性在于它是典型的O2O线下场景——买卖双方基本都是校内学生交易时需要当面验货。接入支付意味着你需要处理退款、纠纷、手续费等一系列问题远远超出了一个毕设或练习项目的合理范围。但完全不设计订单也不对否则用户发了物品怎么标记成交总不能让卖家直接删帖吧。所以我设计了极简订单表只记录“买家对某个物品发起订单”状态机为待确认→已确认等待交易→已完成。卖家可以确认或拒绝订单双方在详情页可以互相看到联系方式完成线下交易交易完成后由买家或卖家标记完成。这个设计既满足了业务闭环又不至于把支付体系牵扯进来。2.2 数据表设计的关键取舍我最终设计了六张核心表用户表(user)、分类表(category)、物品表(item)、订单表(orders)、收藏表(favorite)、留言表(comment)。这里重点说说物品表它是整个系统的核心实体。字段列表大致如下字段类型说明idbigint主键user_idbigint发布者IDcategory_idint分类IDtitlevarchar(50)物品标题descriptiontext物品描述pricedecimal(10,2)价格original_pricedecimal(10,2)原价可选imagesvarchar(500)图片路径多张用逗号分隔statustinyint0在售/1已下架/2已售出view_countint浏览量created_timedatetime发布时间updated_timedatetime更新时间有几个字段需要特别说明设计理由。第一是status字段。很多初学者会用“is_deleted”这种布尔值来标识物品是否被删除但实际业务中物品的状态是有多个的正常在售、卖家手动下架比如暂时不想卖了、已成交、被管理员下架。单纯布尔值无法表达这些状态所以在设计时直接用一个tinyint类型用不同的数值代表不同的业务含义。顺便说一个经验不要把“逻辑删除”和“业务状态”混在同一个字段里逻辑删除建议单独用一个deleted标记。第二是images字段用逗号分隔存储多张图片路径。这在数据库层面不满足第一范式但在这种图片数量有限通常不超过5张、不需要按图片维度查询的业务场景下这种冗余存储的做法反而是最务实的。如果按范式拆出一张item_image表你需要多维护一套增删改查逻辑收益却非常有限。分类表在设计时使用了两级分类父级分类ID为0表示顶级分类否则表示子分类。这样实现了学校闲置场景最常见的分类结构比如“数码产品”下可以有“手机”、“电脑”、“耳机”等子分类。2.3 关于ORM选型MyBatis-Plus的实践体会后端持久层框架我选择的是MyBatis-Plus而不是Spring Data JPA或者原生MyBatis。这个选择对新手来说更容易上手对老手来说也更实用。MyBatis-Plus最大的价值在于它提供了一套内置的通用Mapper和通用Service单表CRUD几乎不需要手写SQL直接继承BaseMapper然后用LambdaQueryWrapper构造条件查询即可。比如实现条件分页查询的核心代码LambdaQueryWrapperItem wrapper new LambdaQueryWrapper(); wrapper.eq(Item::getStatus, 1) .eq(StringUtils.hasText(itemQuery.getCategoryId()), Item::getCategoryId, itemQuery.getCategoryId()) .like(StringUtils.hasText(itemQuery.getKeyword()), Item::getTitle, itemQuery.getKeyword()) .orderByDesc(Item::getCreatedTime); PageItem page new Page(pageNum, pageSize); itemMapper.selectPage(page, wrapper);这种写法一方面极大减少了样板代码另一方面保留了直接写XML自定义SQL的灵活性。比如后面做的“热门物品推荐”“关联物品查询”这类带复杂条件的查询我可以直接在Mapper XML里写原生SQL处理二者并不冲突。如果我当时选择原生MyBatis光是用户、物品、订单三张表的CRUD操作就需要写几十个XML文件工作量大、容易出bug、还不出彩。选择JPA的话虽然也能做到类似效果但JPA对于动态SQL和复杂条件的掌握曲线偏陡很多人会在级联查询上踩坑而且国内企业用的比例远低于MyBatis体系。在技术和就业实用性的平衡之间MyBatis-Plus是一个很务实的折中方案。关于MyBatis-Plus还有两个需要注意的细节。一是分页插件的配置在较新版本中只需注册一个MybatisPlusInterceptor加入PaginationInnerInterceptor即可程序才能返回真正的分页数据。很多人的分页失效问题都出在这个拦截器没有配对。二是逻辑删除配置在application.yml中设置mybatis-plus.global-config.db-config.logic-delete-field: deleted然后实体对应字段上加TableLogic注解这样deleteById走的其实是UPDATE语句对重要数据是一种保护。3. 后端核心模块的实现登录鉴权、图片上传与订单状态机后端开发的环节最考验对SpringBoot生态的熟悉程度。这一段我按模块拆解每个模块都包含设计思路和关键代码片段都是可以直接复用的部分。3.1 登录鉴权方案JWT拦截器还是Spring Security我先说结论对于这类中小型系统首选方案是JWT拦截器而不是整套Spring Security。Spring Security功能强大但也意味着引入了巨大的概念负担过滤器链、认证管理器、密码编码器、安全上下文……你花一周时间研究它的配置逻辑画出来的业务代码可能只有两页纸。对本项目来说所有接口的受保护程度可以划分为两类需要登录发布物品、下单、留言和公开访问浏览、搜索、查看详情完全用不上Security的项目级权限模型角色、菜单、数据权限。JWT方案的落地非常清晰用户登录成功后后端生成令牌包含用户ID和过期时间用HMAC密钥签名前端将令牌存储在localStorage中每次请求在Header中携带Authorization: Bearer token后端拦截器统一校验token并解析用户信息放入ThreadLocal供业务层使用实际使用的核心代码如下Component public class JwtUtil { private static final SecretKey KEY Keys.hmacShaKeyFor(your-secret-key-change-this.getBytes()); public String generateToken(Integer userId, String username) { return Jwts.builder() .setSubject(String.valueOf(userId)) .claim(username, username) .setExpiration(new Date(System.currentTimeMillis() 1000 * 60 * 60 * 24 * 7)) .signWith(KEY) .compact(); } public Claims parseToken(String token) { return Jwts.parserBuilder().setSigningKey(KEY).build() .parseClaimsJws(token).getBody(); } }Token有效期设为7天对校园场景完全够用不存在长期挂机的需求。为了照顾用户体验前端在Axios请求拦截器里统一做token附加和401跳转处理同一个逻辑不用在每页重复实现。需要反复提醒的是JWT的密钥决不能硬编码在代码里直接提交到Git仓库。我在本地开发时用随机字符串临时顶替正式部署时改为从环境变量读取Value(${jwt.secret})配合启动参数传入避免仓库泄露。3.2 物品发布与图片上传本地存储必须考虑的目录约束校园闲置物品系统有一个绕不开的功能——图片上传。这里有两种选择直接传文件到服务器本地或者接入MinIO/OSS这类对象存储。考虑到部署环境是一台轻量服务器我选了本地存储方案本质上就是把这个能力手动实现。核心逻辑其实简单SpringBoot接收MultipartFile将文件写入指定目录返回访问路径。但有几个坑务必要注意都是我自己踩过的。第一个是上传目录的隔离。如果直接把文件写到项目的src/main/resources下打包成Jar后发布文件写入的路径会指向Jar包内部——生产环境根本不能这么玩而且Jar包内的文件是不可写的。正确做法是把用户上传的文件放到服务器上一个独立的绝对路径比如/home/ubuntu/uploads然后用映射方式让外部可以访问Configuration public class WebConfig implements WebMvcConfigurer { Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/upload/**) .addResourceHandler(file: uploadPath /); } }这样访问http://localhost:8080/upload/xxx.jpg就能读取到/home/ubuntu/uploads/xxx.jpg的文件。第二个是文件名要防冲突。我用的是日期前缀 UUID 原始扩展名的组合方式避免用户上传重名文件互相覆盖也避免文件名包含中文或特殊字符导致访问时编码异常。3.3 订单状态机看似简单却最容易写乱的部分订单模块的状态流转是这个项目里逻辑性最强的部分也是最容易暴露设计漏洞的部分。我定义的订单状态为PENDING待卖家确认→CONFIRMED已确认待交易→COMPLETED已完成以及两个边缘状态CANCELLED取消、REJECTED卖家拒绝。关键的业务规则有四个一个物品只能有一条有效订单状态非取消/拒绝物品下架时同时将处于待确认/已确认状态的订单作废订单完成时物品状态改为“已售出”任何状态转移都要校验当前状态是否合法为什么强调状态机设计因为很多人在做这种功能时只关注“if-else能跑”没有定义完整的合法转移路径。结果就会出现这种bug买家取消的订单卖家还能确认成交物品已经下架了买家依然能下单成功。我这里用最简单的方法保证正确性状态转移统一收敛到一个方法里不符合转移条件的抛出业务异常private OrderStatusEnum transition(OrderStatusEnum from, OrderStatusEnum target) { SetOrderStatusEnum allowed TRANSITION_MAP.get(from); if (allowed null || !allowed.contains(target)) { throw new BizException(非法的订单状态变更: from - target); } return target; }TRANSITION_MAP是一张静态的允许转移表一目了然也方便以后扩展新状态。这段逻辑虽然简单但它体现的是“把状态流转集中管理”的设计意识写在简历上也是可以讲上几句的东西。3.4 搜索与分页的细节数据库字段设计的现实反馈搜索功能虽然只是一个LIKE查询加一个分页但有一个容易被忽视的细节是搜索时只能搜索“在售”状态的物品。这个看似自然的约束如果设计时没有放在where条件里就会出现卖家已经下架的物品依然能被搜到的低级事故。分页参数我用的是最普通的pageNum和pageSize返回数据结构是MyBatis-Plus的Page对象前端只需要records、total、current、pages这四个字段。这里有一个前后端配合的细节接口返回的字段名要和前端约定好比如total是总条数、pages是总页数而不是前端自己推一个pageCount出来。这类约定问题在联调阶段特别折腾早定义清楚能省大量沟通成本。4. 前端Vue落地的关键页面路由设计、表单交互与Axios封装Vue前端的工程化程度直接决定开发体验。这一节把前端部分的几个核心模块讲清楚尤其是那些“文档不会写但你一定会碰到”的细节。4.1 项目初始化与路由设计我用Vue CLI初始化项目vue create campus-market选择Vue Router Axios Sass。如果您现在重新做这个项目可以考虑Vite Vue 3的组合构建速度有质的提升但是Vue 2的生态和周边资料更丰富对刚入门的前端同学来说更友好。两种选择没有绝对对错关键是你对哪套技术更熟。路由划分上我用的是“懒加载”方式组织比如首页路由配置为{ path: /, name: Home, component: () import(../views/Home.vue) }这个写法的好处是应用首屏不会一次性把所有页面的JS都加载下来而是访问到对应路径时才按需加载。项目页面一多这个差异在弱网环境下非常明显。路由还有一个容易踩坑的点页面刷新后404问题。部署时如果前端是history模式路由没有#后端需要配置“所有未匹配路径都转发到index.html”。我在Nginx配置里加了try_files $uri $uri/ /index.html;才修复了直接刷新子页面白屏的问题。4.2 商品详情页与图片展示商品详情页是这个系统的门面交互细节最值得打磨。物品图片最多5张主图切换用了一个简单的缩略图列表实现。这个组件的美观和流畅度对用户第一印象影响很大可以自己实现也可以引入Viewer.js等现成插件。我的选择是首版自己写逻辑就是“点击缩略图更新主图src”代码量很少效果也足够。详情页还有一个体现产品意识的功能查看联系方式。买家必须点击“联系卖家”按钮才会展示卖家的微信号或手机号而不是进页面就全部暴露。原因很简单防止非买家用户随意获取联系方式也增加了一丝仪式感和真实性。后端接口在返回详情时默认不携带联系方式只有发起订单后再单独调用一个“获取联系方式”接口——这个细节如果被问到设计动机是非常加分的产品思维。4.3 Axios封装与统一错误处理前端HTTP请求的封装直接影响到联调效率。我在src/utils/request.js里统一创建了一个Axios实例const service axios.create({ baseURL: /api, timeout: 10000 }); service.interceptors.request.use(config { const token localStorage.getItem(token); if (token) { config.headers[Authorization] Bearer token; } return config; }); service.interceptors.response.use( res { const code res.data.code; if (code 401) { router.push(/login); return Promise.reject(new Error(未登录)); } if (code ! 200) { // 统一提示错误信息 return Promise.reject(new Error(res.data.message || 服务器异常)); } return res.data.data; }, error { // 超时/网络异常统一处理 } );这个封装的价值非常直接所有业务调用方只需要关心“data”部分不用每个页面都做一遍错误处理登录过期自动跳回登录页所有非200的业务错误统一提示。新写一个API请求只需要三行代码联调效率提升一大截。4.4 状态管理的克制使用这个项目我一开始用了Vuex后来在重构时反而把大部分状态从Vuex移除了。最后Vuex里只剩一个userInfo当前登录用户的资料其他数据都留在各自页面组件内部。原因很朴素状态管理的核心价值在跨页面共享和跨组件通信而这个项目的绝大多数数据从接口拉取后只在当前页面使用放进全局只会让数据流向混乱。这个经验想说明一个很重要的道理技术选型不一定要“把能用的都上”而是选择“够用且不增加心智负担”的方案。如果面试时被问“为什么没有大量使用Vuex”这个回答本身就体现了对状态管理的理解深度而不是被工具绑架。4.5 前端开发时的调试工具说到前端调试Vue提供了Vue Devtools浏览器扩展这个插件对调试组件props、事件、Vuex状态非常有帮助基本是Vue开发人员的必需品。如果是Electron等桌面应用开发也可以配合Vue Devtools调试渲染进程里的Vue应用。开发期的调试体验能在很大程度上决定你排查问题的效率建议在动手敲代码前先把环境配齐。5. 前后端联调接口约定比编码更值得花时间在这个阶段吃过亏的人应该都明白前后端分离项目最大的成本不在单独的前端或后端而在联调。5.1 统一响应体设计接口返回结构的约定属于联调的“宪法”。我的约定非常简单{ code: 200, message: success, data: { } }后端通过一个Result类统一包装所有Controller方法都返回这个结构前端Axios拦截器统一解包。这个约定需要在项目开始的第一个工作日就定下来不然后端返回字符串、前端又只取字段到处是类型不匹配。5.2 跨域问题的处理开发环境下前端运行在8080端口后端运行在8080端口必然存在跨域。我的处理方式是用SpringBoot的CORS配置在WebMvcConfigurer的实现里配置允许的来源、方法和请求头。更接近生产环境的做法是接Nginx反向代理将/api前缀的请求转发到后端服务再由Nginx统一解决跨域。生产环境我最终采用的就是Nginx方案前端所有请求都发给后端地址而非直接发给Java服务的独立端口。这里有个很容易踩的坑如果你用了Spring Security跨域配置要放在安全过滤链之前生效否则预检请求OPTIONS请求会被安全机制拦截。本项目用的JWT拦截器处理思路类似需要把OPTIONS请求直接放行。5.3 时间格式与枚举值的传输约定联调环节还有一个容易被忽略的细节日期时间格式和枚举值的传输。后端返回LocalDateTime默认序列化格式是类似2025-06-15T21:30:00的这种带T的ISO格式前端直接显示的话不友好。需要在application.yml里统一配置日期格式spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8枚举值也一定要用数字或约定的字符串传输不能把中文状态名直接下发给前端比如订单状态用0/1/2配合前端字典映射显示避免前后端因本地化语言产生歧义。这些看起来不起眼的小约定是联调痛苦指数的最大决定因素。5.4 用统一接口文档工具提升协作效率我用了YApi做接口文档管理现在Smart-Doc、Apifox也很流行。开发过程中所有接口的定义、参数说明、示例返回都维护在工具里前端拿到文档就可以在等后端期间用Mock数据开发页面开发时间几乎可以并行缩短一半。很多自学做项目的人不习惯写文档我强烈建议至少在接口联调阶段维护一份因为在正式工作中没有文档的项目后期维护成本高得惊人。6. 部署上线的实际操作从打包到Docker的一路踩坑系统开发完成之后真正的考验才开始——把前后端项目部署到一台真实的Linux服务器上让它稳定跑起来。6.1 后端打包的坑SpringBoot项目使用Maven打包最容易犯的错误是打包时跳过测试。如果项目里有测试类其中某些测试需要数据库连接而打包机器上没数据库打包直接失败。常规做法是mvn clean package -DskipTests跳过测试。还有一次遇到输出目录里找不到application.yml排查了半天原来是配置文件放错了目录导致SpringBoot启动时用内置配置而不是我们自定义的配置。还有版本兼容问题SpringBoot版本如果选得太新对应依赖的兼容性会带来额外麻烦。我最终用了当时的稳定版本既不是最新也不是太旧目的是降低各种未知坑的可能。6.2 前端打包与Nginx部署前端npm run build生成dist目录把dist目录丢到服务器的Nginx站点根目录然后配置server { listen 80; server_name your-domain-or-ip; root /home/ubuntu/dist; index 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; } location / { try_files $uri $uri/ /index.html; } }这里的核心技巧有两个/api/前缀的请求反向代理到后端的8080端口并且proxy_pass的URL以/结尾时会把/api前缀去掉。比如前端请求/api/auth/login时后端实际收到的是/auth/login所以后端Controller不需要写/api前缀。这个前后端约定要一致否则联调永远对不上。location /配合try_files确保前端路由在history模式下刷新不404。6.3 数据库与图片目录的持久化如果是用Docker部署必须注意数据卷挂载否则容器销毁数据就全部丢失。我的部署方案是用docker-compose同时启动MySQL、后端应用和图片目录version: 3 services: mysql: image: mysql:8 environment: - MYSQL_ROOT_PASSWORDyourpass - MYSQL_DATABASEcampus_market volumes: - /home/ubuntu/mysql-data:/var/lib/mysql ports: - 3306:3306 app: build: ./backend environment: - SPRING_DATASOURCE_URLjdbc:mysql://mysql:3306/campus_market?useSSLfalsecharacterEncodingutf8 - SPRING_DATASOURCE_USERNAMEroot - SPRING_DATASOURCE_PASSWORDyourpass - JWT_SECRETyour-random-secret volumes: - /home/ubuntu/uploads:/app/uploads ports: - 8080:8080 depends_on: - mysql上传图片放宿主机目录数据库放另一个目录容器只做运行时环境——这三个一起解决才算真正把项目部署稳妥。部署完成后也做了一次简单的性能基本检查用JMeter压了一下核心接口在100并发下接口平均响应时间在50毫秒左右数据库连接池和CPU都无明显瓶颈。这个量级对于校园场景来说是足够了如果之后注册用户过万、并发上到几百可以考虑加Redis缓存热点物品数据但那是后话了。6.4 start.sh脚本一键启动的工程化思维我顺手写了一个start.sh脚本把拉代码、构建前端、构建后端、重启服务、检查健康状态整成一条命令。虽然项目本身不大但这个习惯对以后维护和交接都有很大帮助也避免了自己手动敲一串命令时敲错中间的某个参数。7. 从开发到答辩我总结的几点实用经验最后聊一些软性的经验可能比技术细节更能帮到你。第一文档要边做边写。这里的文档既包括数据库设计说明、接口文档也包括开发日志。我见过太多人项目做完了再补文档写得非常痛苦而且会漏掉很多细节。把文档维护当成项目的一部分工作去做毕业答辩时你说话会非常有条理因为你对每个决策的理由都清清楚楚。第二安全边界意识体现在细节里。这个系统没有引入Spring Security但不代表完全不做防护。表单的XSS过滤、SQL注入防护MyBatis的#{}天然防注入、文件上传的类型校验和大小限制这些是基本功都必须有。有些初学项目只看功能不看安全性答辩时被老师问一句“你这个接口为什么不登录也能访问”就很难收场。第三性能优化要有的放矢。对于校园级应用SQL慢查询的排查能力比缓存方案更重要。MyBatis-Plus可以通过打印SQL日志辅助定位问题项目里加上mybatis-plus.configuration.log-implorg.apache.ibatis.logging.stdout.StdOutImpl开发期可以直观看到每句SQL是否合理。第四差错是自己的老师。说实话这个项目我做下来踩的坑远比看教程多Nginx反斜杠路径问题、axios拦截器造成的无限循环请求、逻辑删除字段和状态字段的混淆、Vue路由重复跳转报错……每一个坑后来都成了我讲项目时最有底气的细节。不用怕踩坑但要学会把坑记录下来、讲清楚原因。整个项目从需求梳理到上线运行大约花了六周业余时间第一周做需求和数据设计第二三周做后端核心接口第四周做前端页面和联调第五周测试修bug和部署第六周补文档和准备答辩材料。这个节奏供你参考只要不是从零开始学Java和Vue这个周期内完成完全来得及。如果你在做的过程中遇到具体问题无论是某个接口的设计还是某个框架报错欢迎来交流。