1. 项目概述与整体设计思路1.1 这个系统到底解决了什么问题先聊聊我做这个项目时的真实感受。校园失物招领这件事听起来简单实际上一旦人多起来就特别混乱。我在学校时见过线下失物招领处的桌子堆满水杯、雨伞、校园卡失主找一圈翻不到捡到东西的同学登记完也不知道东西最后有没有物归原主。管理老师的台账更是一本厚厚的Excel查询、统计全靠手工效率低到让人崩溃。所以当时决定把校园失物管理系统作为毕业设计时我给自己定的目标不是交一份作业而是真正能把失物登记、招领管理、认领审核、消息通知、数据统计这些环节全部线上化形成一套完整的业务闭环。这个系统最终做出来后覆盖了三个核心用户角色普通学生、管理员比如失物招领处的老师以及系统层面的维护人员。从功能上看它做的事情可以概括为三件第一让捡到东西的人能在几分钟内完成失物登记并拍照上传第二让丢了东西的人能通过关键词搜索、分类筛选快速锁定可能找到自己物品的招领信息第三让管理员能统一审核每一条认领申请防止错领、冒领。这些听起来简单但真正落地时涉及的表结构设计、权限控制、状态流转、文件上传、前后端联调每一个环节都值得拆开细讲。1.2 技术选型为什么是Spring Boot Vue现在很多同学做毕设一上来就问哪个技术栈最火我个人的看法是对于校园失物管理系统这种典型的CRUD业务系统Spring Boot Vue是目前最稳妥、资料最全、面试也能讲出东西的组合。下面我从三个角度分析一下为什么是这个组合。第一是隔离性。前端Vue负责页面渲染和交互后端Spring Boot只提供RESTful接口两边通过JSON通信。这意味着开发时可以并行推进我在做后端的时候前端同学可以拿Mock数据先写页面效率翻倍。而且以后就算要换个前端框架后端接口不受任何影响。第二是生态成熟度。Spring Boot在Java后端领域基本是事实标准内置Tomcat、自动配置、开箱即用省掉了一大堆XML配置。Vue在前端框架中以学习曲线平缓著称配合Element UI组件库两天就能把后台管理页面的框架搭建起来。对于毕业设计这种周期紧凑的项目来说再也不需要去啃那些陈旧过时的SSH集成文档了。第三是面试有话说。Spring Boot的自动配置原理、起步依赖机制、Vue的响应式数据绑定、组件通信、路由守卫……这些知识点掰开揉碎都能讲很久。我后面在面试时被问到谈谈你毕业设计的技术难点直接就能把认领审核的状态流转、图片上传的处理流程拿出来讲比背八股文不知道强了多少倍。1.3 功能模块划分与权限设计整个系统在功能上划分为两大端用户端和管理端。用户端面向所有在校学生功能包括用户注册登录、挂失信息发布、招领信息发布、搜索与分类筛选、在线认领申请、个人中心管理我发布的、我认领的。管理端面向管理员功能包括成员管理用户禁用/启用、挂失管理、招领管理、认领审核、公告发布、数据统计面板。这里我重点讲讲权限设计。用户端和管理员虽然登录入口是一样的但进入系统后看到的菜单和可操作接口完全不同。我在后端通过拦截器加Token校验的方式做了两层控制第一层是登录校验所有的 /api/** 接口除了注册登录外都要求请求头携带Token否则直接返回401第二层是角色校验只有管理员Token才能访问 /admin/** 的接口普通用户访问时返回403。前端的配合是在路由配置里加了meta标记{ path: /admin, component: Layout, meta: { requiresAdmin: true }, children: [...] }然后在全局前置守卫里校验用户信息里的role字段。前后端双重校验保证就算有人绕过前端直接调用接口后端也会拦截住这一点对答辩时的安全性质询尤其关键。2. 数据库表结构设计与后端核心实现2.1 遵循高内聚低耦合的数据库设计数据库是整个系统的地基。我在设计时把核心表拆成了六张用户表user、挂失表lost_item、招领表found_item、认领申请记录表claim_record外加留言表message和公告表notice。用户表是基础字段包含id、用户名、密码BCrypt加密存储、昵称、学号/工号、联系电话、角色0学生 1管理员、状态0正常 1禁用、创建时间。注意密码一定不能明文存Spring Security自带的BCryptPasswordEncoder可以拿来直接用。挂失表和招领表结构类似都包含物品名称、物品分类、物品描述、丢失/拾取地点、丢失/拾取时间、图片URL、联系QQ或微信、状态、发布人ID、发布时间。区别在于业务性质和状态流转不同挂失信息的物品是等待被认领的而招领信息里的物品是等待失主来认领的。这里我反而建议把失物和招领拆成两张表不要图省事合并因为后续扩展场景、统计口径完全不一样。认领申请记录表是关键表。两个外键分别指向失主或者拾主用户ID、招领/挂失物品ID外加申请说明、申请时间、处理状态0待审核 1已通过 2已驳回、审核备注、审核时间。这张表承载了系统最重要的业务逻辑建议所有新建表都加上create_time和update_time字段别问为什么做过的都懂。2.2 Spring Boot工程结构要怎么搭才不乱工程结构这块因为是一个单体项目我建议用经典的分层架构Controller - Service - Mapper三层。不过在实际写的时候三层之间最好加一层DTO/VO的转换不要在Controller层直接暴露出数据库实体字段。举一个很重要的例子我们查询招领列表时最多返回物品信息加发布人昵称但绝对不应该把发布人的密码字段序列化出去。所以我专门写了ItemVO类只包含前端需要的字段并在Service层完成从Entity到VO的转换。核心的pom.xml依赖只需要这几个起步依赖就足够了spring-boot-starter-web、mybatis-plus-boot-starter、mysql-connector-java、lombok、spring-boot-starter-validation。配一个application.yml的示例server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/campus_lost_found?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: 123456 servlet: multipart: max-file-size: 10MB max-request-size: 50MB mybatis-plus: mapper-locations: classpath:mapper/*.xml configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImplMyBatis Plus用起来确实省心BaseMapper已经把单表的增删改查全都封装好了我们只需要在Service里写业务逻辑。但有一点必须说明MyBatis Plus的驼峰映射默认是开启的如果你的数据库字段是下划线风格比如create_time实体类是驼峰风格createTime它帮我们自动转换完全不用额外配置。2.3 核心业务逻辑认领审核的状态流转认领审核是整个系统业务逻辑最复杂的部分我用一个状态机来管理。所谓状态机本质上就是把业务状态的变化提炼成一个单向流转图让代码的每一次状态变更都有据可依而不是随手乱改。拿招领物品被认领这个流程举例。拾主发布一条招领信息后物品状态是待认领。学生在详情页看到物品点击认领申请按钮填写自己的凭证说明比如校园卡号、物品特征这时系统会生成一条claim_record记录状态是待审核同时物品本身状态不变。管理员在后台看到待审核的申请后点通过claim_record状态变成已通过物品状态变成待领取随后失主线下拿到物品拾主或者管理员在系统里点击确认物品状态才最终变成已完成。如果管理员审核不通过claim_record状态变为已驳回物品状态恢复为待认领。业务上还有一个比较关键的约束同一件物品只能有一条审核通过的认领记录。这个约束我在claim_record表上做了一个联合唯一索引防止并发情况下出现同一件物品被多个人同时认领成功的问题。我给出一个简化版的Service代码Transactional public boolean claimItem(Long userId, Long foundItemId, String claimReason) { // 1. 校验物品是否存在且状态为待认领 FoundItem item foundItemMapper.selectById(foundItemId); if (item null || item.getStatus() ! 0) { throw new RuntimeException(物品不存在或已被认领); } // 2. 检查用户是否已经认领过该物品 Integer count claimRecordMapper.selectCount( new LambdaQueryWrapperClaimRecord() .eq(ClaimRecord::getUserId, userId) .eq(ClaimRecord::getFoundItemId, foundItemId) .eq(ClaimRecord::getStatus, 0)); if (count 0) { throw new RuntimeException(请勿重复申请); } // 3. 插入认领申请记录 ClaimRecord record new ClaimRecord(); record.setUserId(userId); record.setFoundItemId(foundItemId); record.setClaimReason(claimReason); record.setStatus(0); claimRecordMapper.insert(record); return true; }这里有几个细节需要特别提醒。第一非查询接口建议都加上Transactional事务注解这样一旦中间抛异常数据库不会留下脏数据。第二业务状态在代码中不要写死数字建议用一个枚举类比如ItemStatusEnum、ClaimStatusEnum管理阅读起来清晰也不容易出错。第三LambdaQueryWrapper的写法比普通的字符串QueryWrapper安全因为它是编译期检查字段名不会出现拼错字段导致运行时报错的问题。2.4 图片上传与访问路径处理失物照片和招领照片是系统的核心信息载体但在Spring Boot中实现图片上传有几个坑必须要说。我当时的实现方式是这样的controller接收MultipartFile文件校验非空、校验大小限制10MB以内、校验扩展名只允许jpg/png/gif/webp然后用UUID生成新文件名避免重名。保存路径采用本地磁盘存储springBoot启动时在用户目录下创建一个upload文件夹文件按日期分子目录存放比如2025/01/15/xxxxx.jpg。文件上传成功后把相对访问路径比如 /upload/2025/01/15/xxx.jpg存入数据库的img字段。接下来要让前端能访问到这个图片必须配置静态资源映射。在Spring Boot中只需要实现WebMvcConfigurer接口重写addResourceHandlers方法Override public void addResourceHandlers(ResourceHandlerRegistry registry) { String uploadPath System.getProperty(user.dir) File.separator upload File.separator; registry.addResourceHandler(/upload/**) .addResourceLocations(file: uploadPath); }一个最容易踩的坑是开发时直接用了前端Vue的8080端口或者后端的8080端口当你把图片url写死为localhost时部署到服务器后全是裂图。这里最稳妥的做法是后端接口返回图片时只返回相对路径 /upload/xxx.jpg由前端根据当前环境拼接完整的访问前缀。比如我在Vue中封装一个全局变量开发环境写 http://localhost:8080生产环境就改成服务器地址。3. Vue前端架构与页面交互实现3.1 前端工程化搭建与Axios封装前端我用的Vue 2如果现在重新做我会直接用Vue 3 Vite但对于毕设来说Vue 2的生态最稳、资料最多React的同学请绕道。在创建工程时直接用Vue CLI脚手架vue create campus-lost-found然后安装Vue Router、Vuex/A PiniaVue 2用Vuex 3UI组件库选择Element UI。Element UI对Vue 2的支持非常成熟Table、Form、DatePicker这些组件拿来即用管理后台的开发效率直接起飞。网络请求这块强烈建议在axios实例上做统一封装而不是每个组件里直接调用axios。我在src/utils/request.js里创建了一个axios实例设置了baseURL为 /api然后加请求拦截器和响应拦截器。请求拦截器里从localStorage拿Token放到请求头Authorization。响应拦截器里统一处理错误码401跳登录页403提示无权限500提示服务器异常。后端约定的响应格式是{ code: 200, message: success, data: { } }拦截器里直接return response.data.data让业务代码拿到的直接就是真正的数据对象代码干净很多。另外很多新手容易忽略的是axios默认不会携带Cookie如果你用JWT方案其实关系不大但如果你用Session方案一定要在axios配置里加上 withCredentials: true。3.2 页面模块划分与前端路由设计前端页面我划分成两大类面向普通用户的C端页面和面向管理员的后台页面。C端页面包括登录注册页、首页招领信息流、挂失大厅失物信息流、物品详情页、发布页、个人中心我发布的、我认领的、我的留言。管理端页面包括工作台数据统计、招领审核列表、挂失列表、用户管理、公告管理。前端路由要配合后端权限做控制。C端的页面游客也可以访问但发布信息和认领申请必须登录管理端的页面必须有管理员身份才能进入。我用Vue Router的全局前置守卫实现router.beforeEach((to, from, next) { const token localStorage.getItem(token) if (to.meta.requiresAuth !token) { next({ path: /login, query: { redirect: to.fullPath } }) return } if (to.meta.requiresAdmin) { const role localStorage.getItem(role) if (role ! 1) { next({ path: /403 }) return } } next() })一个比较关键的体验优化是登录之后不要简单地跳回首页而是用redirect参数记录用户原本想访问的页面登录成功后直接跳回去。这个小细节对用户体验的提升非常明显也是我入职之后带新人时经常强调的点。3.3 发布表单与图片多图上传的实现细节发布招领信息页面是整个系统使用频率最高的功能之一它的核心是表单校验和图片上传。Element UI的Form组件自带校验规则我在数据里定义了rulesrules: { title: [{ required: true, message: 请填写物品名称, trigger: blur }], category: [{ required: true, message: 请选择物品类型, trigger: change }], location: [{ required: true, message: 请填写拾取地点, trigger: blur }], description: [{ required: true, message: 请填写物品描述, trigger: blur }] }上传组件用的是el-upload这里特别要说的是不要用el-upload默认的action上传方式而是设置 :auto-uploadfalse手动把文件读到FormData里和表单数据一起提交给后端。这样做的好处是接口只需要一个避免图片先传、表单后传导致的数据不一致问题。如果需要支持同时上传多张图片可以遍历文件列表把多个文件append到同一个FormData中。核心代码示意const formData new FormData() formData.append(title, form.title) formData.append(category, form.category) formData.append(location, form.location) formData.append(description, form.description) for (const file of fileList) { formData.append(files, file.raw) } // 注意这里不能直接设置 Content-Type: application/json axios.post(/api/found/add, formData, { headers: { Content-Type: multipart/form-data } })踩过好几次坑后的心得是用FormData传文件时千万不能让axios自动序列化否则后端会解析不到文件字段。同时后端多文件的接收参数名要和前端append的key保持一致。4. 前后端联调核心场景实操复盘4.1 从发布招领信息到列表展示的完整链路我把系统里最核心的一条链路完整走一遍方便你照着测试。假设我现在拾到了一张校园卡登录系统后进入发布招领信息页面填写物品类型为证件类标题为一食堂门口拾到校园卡地点填第一食堂描述补充卡套是蓝色的应该是某某学院的同学上传两张照片后点击提交。前端做的事情是把表单数据整理成FormData发给 POST /api/found/add。后端的流程是拦截器校验登录状态Controller接收参数并做参数校验Service层把图片文件保存到服务器磁盘、生成访问URL然后把物品信息插入数据库found_item表。返回结果中带上新创建的物品ID。然后我回到首页首页加载时调用 GET /api/found/list?page1size10keyword校园卡。后端Service层先根据条件分页查询再把每条记录的发布人昵称关联查出来组装成ItemVO最后返回分页对象。前端拿到数据后渲染成卡片列表。整个链路测试通过就说明最核心的写入-查询链路是通的正。4.2 认领申请到管理员审核的流程演示接下来模拟失主来认领。另一个学生登录系统后在首页搜索校园卡找到刚才那条招领信息点进详情页调出认领申请弹窗。弹窗里要填写联系方式、认领说明比如我的卡号尾号是8821应该有校园卡卡套。提交后调用 POST /api/claim/add后端创建一条状态为待审核的认领记录同时给这条招领信息增加一条处理中的标记。管理员登录后台在认领审核列表中看到这条申请记录。审核列表页面的核心是数据回显和操作按钮。管理员点击查看详情能够看到物品的照片与描述、申请人的学号与联系方式、认领理由。这些数据来自三个表的信息拼装后端用一个ClaimDetailVO搞定。确认没问题后审核通过此时物品状态从待认领变成待领取。失主线下领走物品之后管理员再点一次确认完成整个流程结束。这个流程在联调时最容易出现的问题就是状态更新不及时。比如用户申请成功后前端页面还显示着待认领这是因为详情页是在申请成功之前请求的数据没有刷新。解决方案就是申请成功后跳转回列表页或重新拉取详情数据不要停留在旧的状态里。4.3 管理后台的统计报表与导出功能管理后台除了审核之外还有一块很重要的能力是数据统计。我在工作台页面用ECharts做了两个可视化图表一个是近六个月的招领信息发布趋势折线图一个是物品分类占比饼图。后端提供两个统计接口分别是 GET /admin/stats/trend 和 GET /admin/stats/category。趋势图的实现是统计最近六个月每个月新增的招领和挂失数量前端用ECharts的Line图展示双折线。分类占比则是从物品表里按category分组聚合前端用Pie图展示。说句实话毕业设计里图表功能是加分项但也是最容易翻车的因为接口数据结构和图表组件的数据要求经常对不上。我的经验是不急着写图表组件先定好接口的返回结构用Postman把接口调试好然后再写前端。饼图的数据格式是 [{name: 证件类, value: 35}]折线图的数据格式是 {months: [2024-08, ...], lost: [..], found: [..]}后端设计返回结构时就要和前端对齐。5. 常见问题排查与避坑指南5.1 跨域问题导致的接口请求失败前后端分离项目最常见的问题就是跨域。如果在浏览器控制台看到 blocked by CORS policy 或者 Access to XMLHttpRequest has been blocked基本就是跨域问题。解决办法有很多种最推荐的是在后端写一个CorsConfig配置类统一放行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); } }这里几个要点allowedOriginPatterns() 配合 allowCredentials(true) 一定要这样写直接 allowedOrigins() 再配合 credentials 会有兼容性问题。还有如果项目里引入了Spring Security跨域配置还要在SecurityConfiguration里也放行OPTIONS请求否则预检请求过不去。另一种办法是开发时用Vue CLI的代理功能在vue.config.js里配置proxy转发把 /api 前缀的请求转发到后端的8080端口。但要注意这只在开发环境生效生产环境还是要靠后端处理跨域。5.2 图片上传成功但访问404这个问题的典型场景是上传接口返回了文件相对路径但浏览器访问 http://localhost:8080/upload/xxx.jpg 时404。排查步骤按照我的经验分三步走。第一步确认文件是否真的保存到了磁盘指定目录。可以在系统的用户目录或项目根目录下检查是否有upload文件夹以及文件是否存在。第二步确认静态资源映射是否生效。在配置类里加了addResourceHandlers之后还要确认这个配置类组件有没有被Spring扫描到。如果配置类放在了子包外面Spring Boot默认是扫描不到这是一个很低级但很容易犯的错。第三步检查路径匹配。比如拦截器里是否对 /upload/** 路径做了拦截把图片请求给拦截下来返回了401或404。我遇到过最隐蔽的一种情况是文件路径里的Linux和Windows差异。开发时在Windows下写的是 File.separator 拼路径部署到Linux服务器后路径分隔符虽然自动变成/但应用权限不够导致文件没能写入服务器目录。这种情况通常看应用报错日志Permission denied字样非常明显。5.3 Long类型主键返回前端精度丢失这个坑非常经典我当时排查了大半天。情况是这样的我用MyBatis Plus默认的ASSIGN_ID策略生成雪花ID作为数据表主键这个ID长度超过JavaScript的Number最大安全整数2^53-1。前端从接口收到ID后最后一位的精度丢失变成了几个0。在列表页点击某个物品想查看详情时传回给后端的ID已经不是真实ID了结果查不到数据。解决办法很简单在Jackson序列化时把Long类型转成String类型给前端一个字符串形式的ID。两种实现方式一种是在配置里配置全局的ToStringSerializer另一种是在实体类的ID字段上加注解 JsonSerialize(using ToStringSerializer.class)。我推荐第二种只在需要的主键字段上加避免影响其它Long字段的语义。5.4 新手最容易犯的10个低级错误这里把我这几年看到的、自己做过的错误整理成一张速查表建议收藏错误描述具体表现正确做法数据库表名和实体类名不一致启动时报Table找不到用TableName注解显式指定表名前端请求参数名和后端不一致接口返回参数为null统一使用DTO层规范字段命名未处理空指针列表页获取某个对象的名称时报500关键查询用Optional或判空MyBatis Plus分页插件未配置分页查询不生效返回所有数据配置MybatisPlusInterceptor加PaginationInnerInterceptor密码明文存储数据库里密码直接可见使用BCrypt加密存储删除数据用物理删除误删后无法恢复逻辑删除字段deletedMyBatis Plus支持前端上传文件未限制类型用户上传一个.exe文件后端和前端都校验文件扩展名查询接口不处理时间参数时区时间相差8小时JDBC连接串加serverTimezoneAsia/Shanghai缺少全局异常处理器一个异常导致整个系统报错用RestControllerAdvice统一处理后端接口不返回统一格式前端每个接口都要判断状态码定义统一Result类code/message/data5.5 答辩时容易被追问的5个系统设计问题最后分享一个实际经历。答辩时老师一般不会让你现场敲代码更多的是针对系统的设计合理性提问。我总结几个高频问题和你应该准备的回答思路第一个问题是数据库表为什么这样设计回答时抓住三点主键用雪花ID保证全局唯一所有表都有创建时间和更新时间字段方便后期维护核心关联字段建立外键索引保证查询效率。第二个问题是如果并发量变大系统哪里会成为瓶颈这个问题是送分题你可以说目前本地部署的学生访问量不大数据库是主要瓶颈可以采用分库分表方案同时把图片上传到对象存储服务引入Redis做热点数据的缓存。第三个问题是密码传输安全如何保证回答思路是前端用HTTPS对外部署时密码传输时可以加盐加密后端使用BCrypt算法存储摘要数据库泄露也无法反推出明文密码。第四个问题是你和别人做的一样你的亮点是什么不要谦虚明确说出来清晰的认领状态机设计、前后端权限双重校验、ECharts统计报表、统一的异常处理体系这些就是你的亮点。第五个问题是系统上线部署需要哪些环境答Java运行环境、MySQL数据库、Node.js构建前端、Nginx做静态资源服务器和反向代理有Docker的话可以直接容器化部署。我做完这个项目之后最大的感受是校园失物管理系统表面上是常见的增删改查但真正把一个业务闭环做完、做顺需要的是前后端联调的全局观。很多同学在做毕设时容易陷入一个误区就是文档写得天花乱坠代码却没有跑通。这套系统如果能真正做到可以演示、可以答辩、可以部署它就不只是一个毕业设计的源码而是一份完整的全栈实战经验。我遇到过好几次验收的时候管理员从发布到审核完整体验一遍流程通畅时那种成就感比拿到优秀毕设证书还爽。