失物招领管理系统这个题目在计算机毕业设计里属于典型的“看着简单、做起来全是坑”的项目。每年都有不少同学选基于SpringBoot的高校失物招领管理系统最后却把课程设计的CRUD直接搬来交差——这其实是把题目做小了。我这两年帮人审过几十个类似项目今天把从选题、设计到落地的完整思路一次性拆开讲适合正在做毕设的同学也适合刚接触SpringBoot、想拿一个较完整项目练手的人。高校场景下的失物招领和大众点评、电商系统最大的不同在于业务闭环东西丢了有人发布、东西捡到有人登记、两边如何匹配、匹配成功后怎么认领、认领后怎么归档。如果只做“发布展示”两个接口那系统就只是个公告板答辩时很难拿出像样的亮点。真正值钱的部分在于“智能匹配”和“认领状态流转”这两块才是能讲技术深度的位置。下面我会从需求拆解、技术选型、数据库设计、核心功能实现到部署排错把整套方案按我自己实际开发的顺序讲清楚。1. 项目定位与需求拆解这题不只是做个CRUD1.1 高校失物招领的真实痛点校园里的失物招领一直是个“高频低效”场景。丢失物品集中在校园卡、身份证、耳机、雨伞、书包、眼镜这几类丢失地点又以食堂、图书馆、教学楼、操场、校车为主。过去靠的是食堂门口的小黑板、宿舍楼的纸质公告、保卫处的失物柜信息分散且更新滞后。同学丢了东西不知道去哪找捡到东西的人也不知道该交给谁更别提“物品描述匹配”这件事了——你在公告栏上看到一行“捡到一副黑色耳机”但没人会写耳机品牌、蓝牙版本、丢失时间丢失者根本不敢来认领。所以一个称得上“管理”的系统至少要覆盖四件事失物登记、招领登记、自动匹配、认领闭环。自动匹配是区别于普通公告板的核心也就是基于时间、地点、物品类别的推荐和关键词搜索认领闭环则要解决“这个人是不是失主”的身份确认问题不是谁点一下“我要认领”就把东西拿走。这两个需求直接决定了数据表怎么设计、接口怎么规划。1.2 为什么选SpringBoot做主框架从技术选型角度看SpringBoot几乎是这类管理系统的标准答案。Spring Boot的本质是对Spring全家桶的再封装它通过自动装配把繁琐的XML配置和Bean注册全部收敛到starter依赖里开发者只需要关注业务代码。启动一个Web服务不需要像传统SSH那样配置一堆XML加一个spring-boot-starter-web就能把内置Tomcat跑起来。更关键的是自动装配原理这也是面试官和答辩老师最常问的SpringBootApplication由SpringBootConfiguration、EnableAutoConfiguration、ComponentScan三个注解复合而成。其中EnableAutoConfiguration通过AutoConfigurationImportSelector读取META-INF/spring.factories或者AutoConfiguration.imports里的自动配置类再用ConditionalOnClass、ConditionalOnMissingBean这些条件注解决定哪些Bean生效。听懂这个逻辑回答“SpringBoot为什么能少写配置”就顺理成章了。另外要说明的是版本选择。现在SpringBoot主推3.x要求JDK17以上并且包名从javax.*换成了jakarta.*如果学校指定的JDK是8或者11老老实实用SpringBoot 2.7.x更稳妥。很多同学遇到“springboot版本太高导致依赖冲突”的问题其实就是没管好版本基线后面第6章我会专门讲。1.3 “智能”体现在哪里标题里带了“智能”两个字别被吓到不需要上AI算法。在这类系统里“智能”可以落到三个具体功能上物品匹配推荐发布丢失信息后系统自动从招领库中通过类别、地点、模糊关键字匹配类似物品并提示用户。消息主动通知有人发布招领且和某个丢失信息匹配时通过WebSocket/站内信主动推送给失主而不是让用户一遍遍刷新。管理端统计分析统计高发丢失地点、高发物品类别、招领归还率用图表展示帮助学校优化失物招领资源配置。这三个点每一个都可以单独立项细讲但本质上不复杂属于“工程化”层面的智能化。答辩时把这些讲清楚比堆砌“基于XX算法”的噱头更有说服力因为每一行代码都真实可答辩。2. 技术选型与整体架构跨平台不是加个手机壳2.1 技术栈全景与选型理由“基于Web的跨平台”这个关键词经常被忽略很多毕业设计到最后只有一个PC页面答辩老师一句“手机能访问吗”就露馅了。跨平台并不是要求你一定要做App而是你的系统要能被PC浏览器、手机浏览器、甚至微信小程序共同访问。我建议的这套技术栈属于性价比最高、代码量可控、答辩有得讲的一种组合层次技术选型选型理由前端Vue3 Vite Element Plus组件生态成熟后台管理界面开发效率高学校普遍有基础移动端适配同一套Vue代码用响应式布局不额外开发App省时省力真正做到跨平台访问后端SpringBoot 2.7.x / 3.x生态完善自动装配代码量少业界主流ORMMyBatis-Plus单表CRUD不需要手写SQL分页好用学习成本低数据库MySQL 5.7 / 8.0数据量小模型稳定毕设绝对够用缓存Redis做验证码、热门搜索、接口缓存体现性能意识对象存储MinIO开源、私有化部署把图片和数据库分离展示工程化能力实时通知WebSocket认领申请、状态变更主动推送比轮询高一个档次鉴权JWT无状态、跨端共享契合前后端分离架构部署Nginx Docker一条命令启动避免答辩现场环境问题选这套组合有个隐藏逻辑每一项都能在答辩时讲清楚“为什么不用另一个方案”。比如为什么用MyBatis-Plus而不是JPA因为管理系统的查询条件多且动态MyBatis系的SQL可控性更强为什么图片不直接传服务器本地因为本地磁盘在打包部署时容易丢迁移麻烦接入MinIO能体现你对生产环境的理解。2.2 跨平台方案同一套API服务多个端跨平台的核心不是写多套代码而是保证后端API的前后端分离架构。SpringBoot只提供JSON接口不关心请求来自PC浏览器、手机Safari还是微信小程序。这样前端可以单独部署后端部署在服务器上通过Nginx做反向代理。如果后面想扩展小程序端只需要新增一个小程序前端项目复用同一套接口业务代码一行不用动。实际操作时有几件事必须提前处理跨域配置、Token校验、响应体结构统一。跨域不配置好前端dev环境的请求会被浏览器拦截响应体不统一前端每个接口都要单独判断错误码代码会写得很乱。我建议后端统一返回ResultT结构包含code、message、data三个字段前端封装一个请求函数统一处理后续加功能时会省非常多事。2.3 项目分层与目录结构SpringBoot项目最怕的就是“Controller里面写SQL”所有业务逻辑堆在一个类里。分层不清楚后期改一个需求要牵连三四个接口答辩老师一看代码就想让你重写。标准做法是四层结构com.example.lostfound ├── controller # 接收请求、参数校验、返回Result ├── service # 业务逻辑匹配、状态流转、事务控制 │ └── impl ├── mapper # MyBatis-Plus接口数据访问 ├── entity # 数据库实体类 ├── dto # 前端传入参数封装避免Entity直接暴露 ├── vo # 前端返回封装可聚合多表字段 ├── config # 跨域、WebSocket、JWT拦截器、MinIO等配置 ├── utils # JWT工具、文件工具等 └── common # 统一Result、异常处理器、枚举类分层带来的直接收益是Controller层只做“接参数、调服务、返回结果”Service层只做业务逻辑Mapper层只做SQL。比如“认领物品”这个动作Service层要同时做“校验认领状态、写入认领记录、更新物品状态、发送通知”四件事如果直接在Controller里写代码会失控。3. 数据库设计状态机比表结构更值钱3.1 核心数据表与关键字段数据库设计决定系统的业务边界。失物招领系统最少需要8张表我把核心表和关键字段列出来可以直接照着建表名关键字段说明userid, username, password, real_name, phone, email, role, avatar, create_timerole区分普通用户、管理员lost_itemid, user_id, title, description, category, location, lost_time, image, status, contact, create_time丢失物品登记found_itemid, user_id, title, description, category, location, found_time, image, status, contact, create_time拾取物品登记claim_recordid, item_id, item_type, claimant_id, reason, proof, status, create_time统一记录丢失和招领两种认领申请noticeid, user_id, title, content, type, is_read, create_time站内信配合WebSocket使用categoryid, name, sort物品分类可管理员维护operation_logid, user_id, action, detail, create_time操作日志体现系统安全设计commentid, item_id, user_id, content, create_time可选功能增加互动性这里有个很容易踩坑的设计决策为什么不把“丢失物品”和“招领物品”合成一张表我试过合成一张表加一个type字段理论上确实更省表但实际开发会发现两者字段语义不同丢失物品关心“丢失时间”招领物品关心“拾取时间”业务状态独立流转。强行合并后每个查询都要带type条件代码里到处是if/else非常痛苦。两张表分开存各管各的状态需要匹配时再用联合查询或应用层逻辑处理反而清晰得多。3.2 业务状态机让认领闭环“状态”是这个系统最容易做崩的地方。物品信息通常有这几个状态已发布、待认领、已认领、已归还、已过期。很多人用字符串随便存结果代码里到处散落着“status.equals(1)”这种魔法值改一个状态就要全局搜索。我建议用枚举类统一管理比如public enum ItemStatus { PUBLISHED(已发布), CLAIMING(待认领), CLAIMED(已认领), RETURNED(已归还), EXPIRED(已过期); }状态流转规则必须想清楚发布后默认为已发布有人提交认领申请时变为待认领失主确认认领后变为已认领失主确认收到物品后变为已归还。这里有一个重要的权限判断普通用户只能把自己发布的物品状态往前推一步管理员可以在特殊情况下强制修改但必须在操作日志中留下记录。状态机设计得好后面写代码几乎不用愁业务流程漏洞。3.3 物品匹配逻辑从LIKE到全文索引匹配是失物招领的“搜索”功能实现方案有三个层次由浅入深第一层是MySQL的LIKE模糊查询也是毕设最稳妥的方案SELECT * FROM found_item WHERE status PUBLISHED AND (title LIKE CONCAT(%, #{keyword}, %) OR description LIKE CONCAT(%, #{keyword}, %)) AND category #{category} ORDER BY create_time DESC;这个方案简单、可控但有两个硬伤一是%关键字%导致索引失效数据量大后查询慢二是只能做“包含匹配”用户搜“校园卡”就匹配不到“一卡通”语义上有偏差。第二层是MySQL全文索引。InnoDB表在MySQL 5.7以上支持中文全文索引但需要指定ngram分词器ALTER TABLE found_item ADD FULLTEXT INDEX ft_search (title, description) WITH PARSER ngram; SELECT * FROM found_item WHERE MATCH(title, description) AGAINST (#{keyword} IN NATURAL LANGUAGE MODE);ngram会把中文按默认长度通常是2个字符切词对“校园卡”“一卡通”这种短词匹配效果还凑合但数据量几百条时性能差异不明显主要是答辩时有话题可讲。第三层是在应用层做基于标签的匹配发布丢失信息时让用户选择物品类别、位置标签比如“电子设备”“图书馆”“食堂”匹配时优先找“同类别 同地点 发布时间相近”的招领记录再按匹配度排序。这一层不需要复杂算法一张匹配规则表加一个评分函数就能实现但效果比纯SQL搜索好很多值得作为亮点呈现。4. 核心功能模块实现最容易被问倒的四个地方4.1 发布与认领主流程的权限控制主流程可以概括为用户A发布丢失信息用户B发布招领信息系统在B发布时尝试匹配A的历史记录并通知AA看到通知后进入招领详情页提交认领申请B在“我的发布”里审核申请确认无误后标记认领完成A确认收到物品流程结束。认领申请这个动作的权限控制要非常小心。提交申请前必须校验物品状态必须是已发布或待认领同时要校验申请人不是发布者本人——不然就会出现“自己丢的东西自己认领自己”的笑话。审核动作只能由发布者操作管理员可以查看所有记录但不轻易修改状态这个原则在Controller层做一次拦截在Service层做二次校验双保险。另外发布信息时联系方式建议做成“脱敏显示”列表页只显示“张同学尾号1234”点击详情后才展示完整联系方式这样能减少恶意获取联系方式的问题也是答辩时一个提升安全意识的小亮点。4.2 MinIO接入图片存储为什么不直接存本地失物招领的物品图片是刚需——丢了校园卡至少要展示个照片吧。最简单的做法是图片直接上传到SpringBoot项目的static/upload目录这个方案在本地开发时没问题但有两个隐患一是项目打包部署后图片放在服务器本地磁盘服务重启或重新部署时文件可能丢失二是前后端分离后图片访问地址和接口地址不一致又要额外配置映射。我用的是MinIO一个开源的对象存储服务和阿里云OSS的API设计很像但可以免费私有化部署。本地用Docker跑起来一条命令docker run -p 9000:9000 -p 9001:9001 \ -v /data/minio:/data \ minio/minio server /data --console-address :9001默认账号密码是minioadmin/minioadmin登录控制台后创建lost-found的bucket并把权限设为公开读。然后在SpringBoot中集成MinIO Java SDK上传代码大概是这个样子MinioClient client MinioClient.builder() .endpoint(http://127.0.0.1:9000) .credentials(minioadmin, minioadmin) .build(); boolean exists client.bucketExists( BucketExistsArgs.builder().bucket(lost-found).build()); if (!exists) { client.makeBucket( MakeBucketArgs.builder().bucket(lost-found).build()); } String objectName UUID.randomUUID().toString().replace(-, ) suffix; client.putObject( PutObjectArgs.builder() .bucket(lost-found) .object(objectName) .stream(inputStream, inputStream.available(), -1) .contentType(contentType) .build());返回给前端的URL就是http://服务器IP:9000/lost-found/文件名直接可以访问。这里有个细节上传时一定自己重命名文件不要用用户上传的原始文件名一是防止文件名冲突二是防止中文文件名或特殊字符导致访问链接异常。还有后端除了接收图片文件还应该限制文件大小和类型SpringBoot的配置项是spring: servlet: multipart: max-file-size: 10MB max-request-size: 10MB超过限制后返回统一异常信息避免用户传一个几百MB的视频把服务器带宽打满。4.3 WebSocket实时通知认领消息不靠轮询失物招领系统里通知是粘住用户的关键功能。如果B刚发布一条“捡到校园卡”正好和A丢失的校园卡匹配系统却要等A自己刷新页面才能看到体验就很差了。实现实时通知的常规方案有两种前端定时轮询接口或者后端WebSocket主动推送。轮询实现简单但浪费资源而且有延迟WebSocket是长连接后端可以即时推送本质上是“让服务器主动找用户”。SpringBoot集成WebSocket并不复杂我建议用Spring的原生WebSocketHandler方案Configuration EnableWebSocket public class WebSocketConfig implements WebSocketConfigurer { Override public void registerWebSocketHandlers(WebSocketHandlerRegistry registry) { registry.addHandler(new NoticeHandler(), /ws/notice) .addInterceptors(new AuthHandshakeInterceptor()) .setAllowedOrigins(*); } }注意握手时要校验JWT把连接和用户ID绑定。每个用户建立连接后在服务端维护一个ConcurrentHashMapString, WebSocketSession用于记录在线连接。新招领信息发布后匹配服务在Service层触发推送// 伪代码匹配成功后推送 Notice notice noticeService.createMatchNotice(lostItem, foundItem); WebSocketSession session sessionManager.get(userId.toString()); if (session ! null session.isOpen()) { session.sendMessage(new TextMessage(JSON.toJSONString(notice))); }这里一定要处理的坑是WebSocket的Session不是线程安全的多线程发送时要用ConcurrentWebSocketSessionDecorator包装或者加锁否则高并发下会抛IllegalStateException。毕设虽然并发不高但如果你在代码里处理了这一点面试官会高看你一眼。4.4 JWT登录鉴权告别Session跨端问题跨平台系统用传统Session有两个麻烦一是Session默认存在服务器内存重启就丢二是手机端、小程序端、Web端共享登录态很别扭。JWT的方案是用户登录成功后服务器签发一个带过期时间的Token返回给前端前端每次请求在Header里带上Authorization: Bearer xxx后端用拦截器校验签名不需要存储Session天然适合跨端。依赖用jjwt版本0.11.xdependency groupIdio.jsonwebtoken/groupId artifactIdjjwt-api/artifactId version0.11.5/version /dependency dependency groupIdio.jsonwebtoken/groupId artifactIdjjwt-impl/artifactId version0.11.5/version scoperuntime/scope /dependency dependency groupIdio.jsonwebtoken/groupId artifactIdjjwt-jackson/artifactId version0.11.5/version scoperuntime/scope /dependency签名密钥必须是32字节以上否则会报WeakKeyException这是新版jjwt的安全策略我当年第一次用就被坑过。签发代码String token Jwts.builder() .setSubject(userId.toString()) .claim(role, user.getRole()) .setExpiration(new Date(System.currentTimeMillis() 7 * 24 * 60 * 60 * 1000L)) .signWith(Keys.hmacShaKeyFor(secretKey.getBytes()), SignatureAlgorithm.HS256) .compact();封装一个JwtInterceptor实现HandlerInterceptor在preHandle中校验Token并解析出用户信息放入ThreadLocal或Request属性里后面Controller就能直接拿到当前登录用户。注意要放行登录接口、图片访问等公开路径其他接口全部拦截。这一步做好了系统的安全性故事就完整了。5. 实操过程从0到1把系统跑起来5.1 项目初始化与环境准备开发环境建议统一为JDK 1.8或11如果是SpringBoot 2.7、Maven 3.6、MySQL 5.7/8.0、Redis 5.0以上、IDEA 2022。项目创建直接在“Spring Initializr”里完成也可以到start.spring.io官网生成压缩包再导入。勾选依赖时模板先只选Spring Web、MySQL Driver、MyBatis Framework剩下的MyBatis-Plus、JWT、MinIO SDK等手动加到pom里更好控制版本。启动基础工程后第一件事不要写业务代码而是先把三层结构建好然后拿“用户注册登录”这个小流程跑通。注册时密码用BCryptPasswordEncoder加密存储这是Spring Security提供的工具类单独引入spring-security-crypto即可不需要引入整套Security。密码以明文存入数据库这种行为在答辩时属于减分项不要碰。5.2 核心配置application.yml与跨域处理application.yml是整个项目最需要谨慎对待的文件我把关键配置整理成了模板式写法server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://127.0.0.1:3306/lost_found?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: 你的密码 redis: host: 127.0.0.1 port: 6379 servlet: multipart: max-file-size: 10MB max-request-size: 10MB jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8 mybatis-plus: mapper-locations: classpath:mapper/*.xml configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0 jwt: secret: 请改成至少32位的随机字符串 expire-days: 7 minio: endpoint: http://127.0.0.1:9000 access-key: minioadmin secret-key: minioadmin bucket: lost-found跨域配置单独放在CorsConfig中开发时一定要允许OPTIONS预检请求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); } }注意allowedOrigins(*)和allowCredentials(true)同时使用在某些浏览器版本会有冲突用allowedOriginPatterns(*)是更稳的写法。5.3 前端打包与部署分离部署和合并部署怎么选开发阶段前端用Vite的dev server配置proxy把/api请求转发到http://localhost:8080实现前后端分离联调。部署时有两种选择第一种是前后端分离部署标准做法是前端打包成静态文件交给Nginx后端SpringBoot单独跑一个进程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; } }注意proxy_pass http://127.0.0.1:8080/;末尾的斜杠会把/api前缀去掉这样后端接口不需要额外处理路径。这是部署时特别容易踩的坑少一个斜杠请求就直接404了。第二种是前后端合并部署把Vue打包后的dist目录拷贝到src/main/resources/static下SpringBoot直接同时提供前端页面和后端接口。这种方式适合答辩现场演示因为只启动一个Java进程不用额外装Nginx。但要注意去掉上面的location /api/代理配置否则会死循环。另外前端路由使用history模式时后端要配置转发规则把非接口路径转发到index.html否则刷新页面会404。6. 常见问题与排查技巧实录6.1 联调阶段高频问题跨域、长整型、日期格式联调期第一个“惊喜”几乎都是跨域。前端口口声声说请求发出去了后端控制台就是看不到原因一般是浏览器因为CORS把请求拦截了根本没到后端。排查方法是先看浏览器控制台的报错信息如果是CORS policy相关就检查后端CorsConfig是否允许了当前域名如果请求是OPTIONS预检失败检查是否有拦截器把预检请求也给拦截了。第二个高频问题是主键Long精度丢失。数据库主键用bigint自增后端的Java类型是Long在前端JavaScript里超过16位之后精度会丢失导致用户看得到ID但点“详情”时携带的ID是错的查出来完全不是同一条记录。解决方法是实体类的ID字段加JsonSerialize(using ToStringSerializer.class)或者全局配置把Long转成String输出。但我建议只对ID字段做转换不要把时间戳之类的Long也全局转成字符串否则前端解析又乱套了。第三个是日期格式问题。后端返回的日期默认是格林尼治时间少了8小时前端显示总比实际时间慢。我见过有人在前端手动加8小时来修的这属于治标不治本。正确的做法是在application.yml配置spring.jackson.time-zone: GMT8和date-format: yyyy-MM-dd HH:mm:ss从源头解决问题。6.2 部署阶段高频问题上传失败、图片403、时区偏移部署到服务器后很多本地开发没问题的事会冒出来。最常见的上传失败是上传文件过大Nginx默认client_max_body_size只有1m前端传一张手机照片就超了报413错误。Nginx配置里要加client_max_body_size 20m;同时后端multipart限制也要同步调大。图片403的问题通常和MinIO的bucket权限有关。检查MinIO控制台里bucket是否设置了公开读权限如果没有公开访问http://IP:9000/bucket/xxx.jpg就会被拒绝。如果是图片能上传但URL打不开先本地执行curl -I 完整URL看返回的状态码403是权限问题404是桶名或者路径写错了。还有一个隐蔽的问题MinIO的endpoint如果写成http://localhost:9000但前端页面通过公网IP访问时生成的图片地址是localhost用户根本点不开。所以MinIO的endpoint配置要写服务器公网IP或者域名。数据库时区设置也要检查。连接串里已经有serverTimezoneAsia/Shanghai如果依然差8小时一般是MySQL自身时区问题执行SET GLOBAL time_zone 8:00;可以临时解决但最佳实践是在配置文件中固定default-time-zone 08:00。6.3 答辩加分经验如何把“亮点”讲清楚答辩时最怕的不是功能少而是“什么都做了但讲不出重点”。我总结的答辩主线是业务痛点 → 状态机设计 → 智能匹配 → 消息通知 → 安全控制 → 部署方案。每一个环节都准备一张图或一段代码作为证据。讲状态机时画出状态流转图解释为什么把失物和招领拆成两张表为什么认领申请要单独建表。讲智能匹配时先用LIKE方案演示再提全文索引或标签匹配优化说明你考虑过数据量增长后的方案演进。讲跨平台时强调“前后端分离同一套API服务多端”最好现场展示手机浏览器访问和PC访问的效果。讲SpringBoot原理时把自动装配条件注解的链路说清楚EnableAutoConfiguration加载哪些自动配置类什么时候生效什么时候通过ConditionalOnMissingBean让位于用户自定义Bean。再补一个容易被忽略的小细节给项目写一个README.md把启动步骤、配置说明、默认账号写清楚。答辩时老师大概率会问“这个系统要跑起来需要哪些环境”如果你能条理清晰地回答印象分会加不少。最后分享一个小习惯做这类管理系统的毕设不要急着写代码先用一天时间把状态机画出来、把表结构定下来再动手。失物招领系统的核心不是增删改查而是“认领闭环”——丢东西的同学提交了信息捡到东西的同学也提交了信息两边能不能对得上、对上了之后怎么安全认领这才是系统存在的价值。把匹配、通知、认领确认这几个环节做扎实哪怕界面朴素一点答辩时都能讲出真东西。希望这篇拆解能帮正在做SpringBoot毕设的同学少走几个坑。
基于SpringBoot的高校失物招领管理系统设计与实现
失物招领管理系统这个题目在计算机毕业设计里属于典型的“看着简单、做起来全是坑”的项目。每年都有不少同学选基于SpringBoot的高校失物招领管理系统最后却把课程设计的CRUD直接搬来交差——这其实是把题目做小了。我这两年帮人审过几十个类似项目今天把从选题、设计到落地的完整思路一次性拆开讲适合正在做毕设的同学也适合刚接触SpringBoot、想拿一个较完整项目练手的人。高校场景下的失物招领和大众点评、电商系统最大的不同在于业务闭环东西丢了有人发布、东西捡到有人登记、两边如何匹配、匹配成功后怎么认领、认领后怎么归档。如果只做“发布展示”两个接口那系统就只是个公告板答辩时很难拿出像样的亮点。真正值钱的部分在于“智能匹配”和“认领状态流转”这两块才是能讲技术深度的位置。下面我会从需求拆解、技术选型、数据库设计、核心功能实现到部署排错把整套方案按我自己实际开发的顺序讲清楚。1. 项目定位与需求拆解这题不只是做个CRUD1.1 高校失物招领的真实痛点校园里的失物招领一直是个“高频低效”场景。丢失物品集中在校园卡、身份证、耳机、雨伞、书包、眼镜这几类丢失地点又以食堂、图书馆、教学楼、操场、校车为主。过去靠的是食堂门口的小黑板、宿舍楼的纸质公告、保卫处的失物柜信息分散且更新滞后。同学丢了东西不知道去哪找捡到东西的人也不知道该交给谁更别提“物品描述匹配”这件事了——你在公告栏上看到一行“捡到一副黑色耳机”但没人会写耳机品牌、蓝牙版本、丢失时间丢失者根本不敢来认领。所以一个称得上“管理”的系统至少要覆盖四件事失物登记、招领登记、自动匹配、认领闭环。自动匹配是区别于普通公告板的核心也就是基于时间、地点、物品类别的推荐和关键词搜索认领闭环则要解决“这个人是不是失主”的身份确认问题不是谁点一下“我要认领”就把东西拿走。这两个需求直接决定了数据表怎么设计、接口怎么规划。1.2 为什么选SpringBoot做主框架从技术选型角度看SpringBoot几乎是这类管理系统的标准答案。Spring Boot的本质是对Spring全家桶的再封装它通过自动装配把繁琐的XML配置和Bean注册全部收敛到starter依赖里开发者只需要关注业务代码。启动一个Web服务不需要像传统SSH那样配置一堆XML加一个spring-boot-starter-web就能把内置Tomcat跑起来。更关键的是自动装配原理这也是面试官和答辩老师最常问的SpringBootApplication由SpringBootConfiguration、EnableAutoConfiguration、ComponentScan三个注解复合而成。其中EnableAutoConfiguration通过AutoConfigurationImportSelector读取META-INF/spring.factories或者AutoConfiguration.imports里的自动配置类再用ConditionalOnClass、ConditionalOnMissingBean这些条件注解决定哪些Bean生效。听懂这个逻辑回答“SpringBoot为什么能少写配置”就顺理成章了。另外要说明的是版本选择。现在SpringBoot主推3.x要求JDK17以上并且包名从javax.*换成了jakarta.*如果学校指定的JDK是8或者11老老实实用SpringBoot 2.7.x更稳妥。很多同学遇到“springboot版本太高导致依赖冲突”的问题其实就是没管好版本基线后面第6章我会专门讲。1.3 “智能”体现在哪里标题里带了“智能”两个字别被吓到不需要上AI算法。在这类系统里“智能”可以落到三个具体功能上物品匹配推荐发布丢失信息后系统自动从招领库中通过类别、地点、模糊关键字匹配类似物品并提示用户。消息主动通知有人发布招领且和某个丢失信息匹配时通过WebSocket/站内信主动推送给失主而不是让用户一遍遍刷新。管理端统计分析统计高发丢失地点、高发物品类别、招领归还率用图表展示帮助学校优化失物招领资源配置。这三个点每一个都可以单独立项细讲但本质上不复杂属于“工程化”层面的智能化。答辩时把这些讲清楚比堆砌“基于XX算法”的噱头更有说服力因为每一行代码都真实可答辩。2. 技术选型与整体架构跨平台不是加个手机壳2.1 技术栈全景与选型理由“基于Web的跨平台”这个关键词经常被忽略很多毕业设计到最后只有一个PC页面答辩老师一句“手机能访问吗”就露馅了。跨平台并不是要求你一定要做App而是你的系统要能被PC浏览器、手机浏览器、甚至微信小程序共同访问。我建议的这套技术栈属于性价比最高、代码量可控、答辩有得讲的一种组合层次技术选型选型理由前端Vue3 Vite Element Plus组件生态成熟后台管理界面开发效率高学校普遍有基础移动端适配同一套Vue代码用响应式布局不额外开发App省时省力真正做到跨平台访问后端SpringBoot 2.7.x / 3.x生态完善自动装配代码量少业界主流ORMMyBatis-Plus单表CRUD不需要手写SQL分页好用学习成本低数据库MySQL 5.7 / 8.0数据量小模型稳定毕设绝对够用缓存Redis做验证码、热门搜索、接口缓存体现性能意识对象存储MinIO开源、私有化部署把图片和数据库分离展示工程化能力实时通知WebSocket认领申请、状态变更主动推送比轮询高一个档次鉴权JWT无状态、跨端共享契合前后端分离架构部署Nginx Docker一条命令启动避免答辩现场环境问题选这套组合有个隐藏逻辑每一项都能在答辩时讲清楚“为什么不用另一个方案”。比如为什么用MyBatis-Plus而不是JPA因为管理系统的查询条件多且动态MyBatis系的SQL可控性更强为什么图片不直接传服务器本地因为本地磁盘在打包部署时容易丢迁移麻烦接入MinIO能体现你对生产环境的理解。2.2 跨平台方案同一套API服务多个端跨平台的核心不是写多套代码而是保证后端API的前后端分离架构。SpringBoot只提供JSON接口不关心请求来自PC浏览器、手机Safari还是微信小程序。这样前端可以单独部署后端部署在服务器上通过Nginx做反向代理。如果后面想扩展小程序端只需要新增一个小程序前端项目复用同一套接口业务代码一行不用动。实际操作时有几件事必须提前处理跨域配置、Token校验、响应体结构统一。跨域不配置好前端dev环境的请求会被浏览器拦截响应体不统一前端每个接口都要单独判断错误码代码会写得很乱。我建议后端统一返回ResultT结构包含code、message、data三个字段前端封装一个请求函数统一处理后续加功能时会省非常多事。2.3 项目分层与目录结构SpringBoot项目最怕的就是“Controller里面写SQL”所有业务逻辑堆在一个类里。分层不清楚后期改一个需求要牵连三四个接口答辩老师一看代码就想让你重写。标准做法是四层结构com.example.lostfound ├── controller # 接收请求、参数校验、返回Result ├── service # 业务逻辑匹配、状态流转、事务控制 │ └── impl ├── mapper # MyBatis-Plus接口数据访问 ├── entity # 数据库实体类 ├── dto # 前端传入参数封装避免Entity直接暴露 ├── vo # 前端返回封装可聚合多表字段 ├── config # 跨域、WebSocket、JWT拦截器、MinIO等配置 ├── utils # JWT工具、文件工具等 └── common # 统一Result、异常处理器、枚举类分层带来的直接收益是Controller层只做“接参数、调服务、返回结果”Service层只做业务逻辑Mapper层只做SQL。比如“认领物品”这个动作Service层要同时做“校验认领状态、写入认领记录、更新物品状态、发送通知”四件事如果直接在Controller里写代码会失控。3. 数据库设计状态机比表结构更值钱3.1 核心数据表与关键字段数据库设计决定系统的业务边界。失物招领系统最少需要8张表我把核心表和关键字段列出来可以直接照着建表名关键字段说明userid, username, password, real_name, phone, email, role, avatar, create_timerole区分普通用户、管理员lost_itemid, user_id, title, description, category, location, lost_time, image, status, contact, create_time丢失物品登记found_itemid, user_id, title, description, category, location, found_time, image, status, contact, create_time拾取物品登记claim_recordid, item_id, item_type, claimant_id, reason, proof, status, create_time统一记录丢失和招领两种认领申请noticeid, user_id, title, content, type, is_read, create_time站内信配合WebSocket使用categoryid, name, sort物品分类可管理员维护operation_logid, user_id, action, detail, create_time操作日志体现系统安全设计commentid, item_id, user_id, content, create_time可选功能增加互动性这里有个很容易踩坑的设计决策为什么不把“丢失物品”和“招领物品”合成一张表我试过合成一张表加一个type字段理论上确实更省表但实际开发会发现两者字段语义不同丢失物品关心“丢失时间”招领物品关心“拾取时间”业务状态独立流转。强行合并后每个查询都要带type条件代码里到处是if/else非常痛苦。两张表分开存各管各的状态需要匹配时再用联合查询或应用层逻辑处理反而清晰得多。3.2 业务状态机让认领闭环“状态”是这个系统最容易做崩的地方。物品信息通常有这几个状态已发布、待认领、已认领、已归还、已过期。很多人用字符串随便存结果代码里到处散落着“status.equals(1)”这种魔法值改一个状态就要全局搜索。我建议用枚举类统一管理比如public enum ItemStatus { PUBLISHED(已发布), CLAIMING(待认领), CLAIMED(已认领), RETURNED(已归还), EXPIRED(已过期); }状态流转规则必须想清楚发布后默认为已发布有人提交认领申请时变为待认领失主确认认领后变为已认领失主确认收到物品后变为已归还。这里有一个重要的权限判断普通用户只能把自己发布的物品状态往前推一步管理员可以在特殊情况下强制修改但必须在操作日志中留下记录。状态机设计得好后面写代码几乎不用愁业务流程漏洞。3.3 物品匹配逻辑从LIKE到全文索引匹配是失物招领的“搜索”功能实现方案有三个层次由浅入深第一层是MySQL的LIKE模糊查询也是毕设最稳妥的方案SELECT * FROM found_item WHERE status PUBLISHED AND (title LIKE CONCAT(%, #{keyword}, %) OR description LIKE CONCAT(%, #{keyword}, %)) AND category #{category} ORDER BY create_time DESC;这个方案简单、可控但有两个硬伤一是%关键字%导致索引失效数据量大后查询慢二是只能做“包含匹配”用户搜“校园卡”就匹配不到“一卡通”语义上有偏差。第二层是MySQL全文索引。InnoDB表在MySQL 5.7以上支持中文全文索引但需要指定ngram分词器ALTER TABLE found_item ADD FULLTEXT INDEX ft_search (title, description) WITH PARSER ngram; SELECT * FROM found_item WHERE MATCH(title, description) AGAINST (#{keyword} IN NATURAL LANGUAGE MODE);ngram会把中文按默认长度通常是2个字符切词对“校园卡”“一卡通”这种短词匹配效果还凑合但数据量几百条时性能差异不明显主要是答辩时有话题可讲。第三层是在应用层做基于标签的匹配发布丢失信息时让用户选择物品类别、位置标签比如“电子设备”“图书馆”“食堂”匹配时优先找“同类别 同地点 发布时间相近”的招领记录再按匹配度排序。这一层不需要复杂算法一张匹配规则表加一个评分函数就能实现但效果比纯SQL搜索好很多值得作为亮点呈现。4. 核心功能模块实现最容易被问倒的四个地方4.1 发布与认领主流程的权限控制主流程可以概括为用户A发布丢失信息用户B发布招领信息系统在B发布时尝试匹配A的历史记录并通知AA看到通知后进入招领详情页提交认领申请B在“我的发布”里审核申请确认无误后标记认领完成A确认收到物品流程结束。认领申请这个动作的权限控制要非常小心。提交申请前必须校验物品状态必须是已发布或待认领同时要校验申请人不是发布者本人——不然就会出现“自己丢的东西自己认领自己”的笑话。审核动作只能由发布者操作管理员可以查看所有记录但不轻易修改状态这个原则在Controller层做一次拦截在Service层做二次校验双保险。另外发布信息时联系方式建议做成“脱敏显示”列表页只显示“张同学尾号1234”点击详情后才展示完整联系方式这样能减少恶意获取联系方式的问题也是答辩时一个提升安全意识的小亮点。4.2 MinIO接入图片存储为什么不直接存本地失物招领的物品图片是刚需——丢了校园卡至少要展示个照片吧。最简单的做法是图片直接上传到SpringBoot项目的static/upload目录这个方案在本地开发时没问题但有两个隐患一是项目打包部署后图片放在服务器本地磁盘服务重启或重新部署时文件可能丢失二是前后端分离后图片访问地址和接口地址不一致又要额外配置映射。我用的是MinIO一个开源的对象存储服务和阿里云OSS的API设计很像但可以免费私有化部署。本地用Docker跑起来一条命令docker run -p 9000:9000 -p 9001:9001 \ -v /data/minio:/data \ minio/minio server /data --console-address :9001默认账号密码是minioadmin/minioadmin登录控制台后创建lost-found的bucket并把权限设为公开读。然后在SpringBoot中集成MinIO Java SDK上传代码大概是这个样子MinioClient client MinioClient.builder() .endpoint(http://127.0.0.1:9000) .credentials(minioadmin, minioadmin) .build(); boolean exists client.bucketExists( BucketExistsArgs.builder().bucket(lost-found).build()); if (!exists) { client.makeBucket( MakeBucketArgs.builder().bucket(lost-found).build()); } String objectName UUID.randomUUID().toString().replace(-, ) suffix; client.putObject( PutObjectArgs.builder() .bucket(lost-found) .object(objectName) .stream(inputStream, inputStream.available(), -1) .contentType(contentType) .build());返回给前端的URL就是http://服务器IP:9000/lost-found/文件名直接可以访问。这里有个细节上传时一定自己重命名文件不要用用户上传的原始文件名一是防止文件名冲突二是防止中文文件名或特殊字符导致访问链接异常。还有后端除了接收图片文件还应该限制文件大小和类型SpringBoot的配置项是spring: servlet: multipart: max-file-size: 10MB max-request-size: 10MB超过限制后返回统一异常信息避免用户传一个几百MB的视频把服务器带宽打满。4.3 WebSocket实时通知认领消息不靠轮询失物招领系统里通知是粘住用户的关键功能。如果B刚发布一条“捡到校园卡”正好和A丢失的校园卡匹配系统却要等A自己刷新页面才能看到体验就很差了。实现实时通知的常规方案有两种前端定时轮询接口或者后端WebSocket主动推送。轮询实现简单但浪费资源而且有延迟WebSocket是长连接后端可以即时推送本质上是“让服务器主动找用户”。SpringBoot集成WebSocket并不复杂我建议用Spring的原生WebSocketHandler方案Configuration EnableWebSocket public class WebSocketConfig implements WebSocketConfigurer { Override public void registerWebSocketHandlers(WebSocketHandlerRegistry registry) { registry.addHandler(new NoticeHandler(), /ws/notice) .addInterceptors(new AuthHandshakeInterceptor()) .setAllowedOrigins(*); } }注意握手时要校验JWT把连接和用户ID绑定。每个用户建立连接后在服务端维护一个ConcurrentHashMapString, WebSocketSession用于记录在线连接。新招领信息发布后匹配服务在Service层触发推送// 伪代码匹配成功后推送 Notice notice noticeService.createMatchNotice(lostItem, foundItem); WebSocketSession session sessionManager.get(userId.toString()); if (session ! null session.isOpen()) { session.sendMessage(new TextMessage(JSON.toJSONString(notice))); }这里一定要处理的坑是WebSocket的Session不是线程安全的多线程发送时要用ConcurrentWebSocketSessionDecorator包装或者加锁否则高并发下会抛IllegalStateException。毕设虽然并发不高但如果你在代码里处理了这一点面试官会高看你一眼。4.4 JWT登录鉴权告别Session跨端问题跨平台系统用传统Session有两个麻烦一是Session默认存在服务器内存重启就丢二是手机端、小程序端、Web端共享登录态很别扭。JWT的方案是用户登录成功后服务器签发一个带过期时间的Token返回给前端前端每次请求在Header里带上Authorization: Bearer xxx后端用拦截器校验签名不需要存储Session天然适合跨端。依赖用jjwt版本0.11.xdependency groupIdio.jsonwebtoken/groupId artifactIdjjwt-api/artifactId version0.11.5/version /dependency dependency groupIdio.jsonwebtoken/groupId artifactIdjjwt-impl/artifactId version0.11.5/version scoperuntime/scope /dependency dependency groupIdio.jsonwebtoken/groupId artifactIdjjwt-jackson/artifactId version0.11.5/version scoperuntime/scope /dependency签名密钥必须是32字节以上否则会报WeakKeyException这是新版jjwt的安全策略我当年第一次用就被坑过。签发代码String token Jwts.builder() .setSubject(userId.toString()) .claim(role, user.getRole()) .setExpiration(new Date(System.currentTimeMillis() 7 * 24 * 60 * 60 * 1000L)) .signWith(Keys.hmacShaKeyFor(secretKey.getBytes()), SignatureAlgorithm.HS256) .compact();封装一个JwtInterceptor实现HandlerInterceptor在preHandle中校验Token并解析出用户信息放入ThreadLocal或Request属性里后面Controller就能直接拿到当前登录用户。注意要放行登录接口、图片访问等公开路径其他接口全部拦截。这一步做好了系统的安全性故事就完整了。5. 实操过程从0到1把系统跑起来5.1 项目初始化与环境准备开发环境建议统一为JDK 1.8或11如果是SpringBoot 2.7、Maven 3.6、MySQL 5.7/8.0、Redis 5.0以上、IDEA 2022。项目创建直接在“Spring Initializr”里完成也可以到start.spring.io官网生成压缩包再导入。勾选依赖时模板先只选Spring Web、MySQL Driver、MyBatis Framework剩下的MyBatis-Plus、JWT、MinIO SDK等手动加到pom里更好控制版本。启动基础工程后第一件事不要写业务代码而是先把三层结构建好然后拿“用户注册登录”这个小流程跑通。注册时密码用BCryptPasswordEncoder加密存储这是Spring Security提供的工具类单独引入spring-security-crypto即可不需要引入整套Security。密码以明文存入数据库这种行为在答辩时属于减分项不要碰。5.2 核心配置application.yml与跨域处理application.yml是整个项目最需要谨慎对待的文件我把关键配置整理成了模板式写法server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://127.0.0.1:3306/lost_found?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: 你的密码 redis: host: 127.0.0.1 port: 6379 servlet: multipart: max-file-size: 10MB max-request-size: 10MB jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8 mybatis-plus: mapper-locations: classpath:mapper/*.xml configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0 jwt: secret: 请改成至少32位的随机字符串 expire-days: 7 minio: endpoint: http://127.0.0.1:9000 access-key: minioadmin secret-key: minioadmin bucket: lost-found跨域配置单独放在CorsConfig中开发时一定要允许OPTIONS预检请求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); } }注意allowedOrigins(*)和allowCredentials(true)同时使用在某些浏览器版本会有冲突用allowedOriginPatterns(*)是更稳的写法。5.3 前端打包与部署分离部署和合并部署怎么选开发阶段前端用Vite的dev server配置proxy把/api请求转发到http://localhost:8080实现前后端分离联调。部署时有两种选择第一种是前后端分离部署标准做法是前端打包成静态文件交给Nginx后端SpringBoot单独跑一个进程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; } }注意proxy_pass http://127.0.0.1:8080/;末尾的斜杠会把/api前缀去掉这样后端接口不需要额外处理路径。这是部署时特别容易踩的坑少一个斜杠请求就直接404了。第二种是前后端合并部署把Vue打包后的dist目录拷贝到src/main/resources/static下SpringBoot直接同时提供前端页面和后端接口。这种方式适合答辩现场演示因为只启动一个Java进程不用额外装Nginx。但要注意去掉上面的location /api/代理配置否则会死循环。另外前端路由使用history模式时后端要配置转发规则把非接口路径转发到index.html否则刷新页面会404。6. 常见问题与排查技巧实录6.1 联调阶段高频问题跨域、长整型、日期格式联调期第一个“惊喜”几乎都是跨域。前端口口声声说请求发出去了后端控制台就是看不到原因一般是浏览器因为CORS把请求拦截了根本没到后端。排查方法是先看浏览器控制台的报错信息如果是CORS policy相关就检查后端CorsConfig是否允许了当前域名如果请求是OPTIONS预检失败检查是否有拦截器把预检请求也给拦截了。第二个高频问题是主键Long精度丢失。数据库主键用bigint自增后端的Java类型是Long在前端JavaScript里超过16位之后精度会丢失导致用户看得到ID但点“详情”时携带的ID是错的查出来完全不是同一条记录。解决方法是实体类的ID字段加JsonSerialize(using ToStringSerializer.class)或者全局配置把Long转成String输出。但我建议只对ID字段做转换不要把时间戳之类的Long也全局转成字符串否则前端解析又乱套了。第三个是日期格式问题。后端返回的日期默认是格林尼治时间少了8小时前端显示总比实际时间慢。我见过有人在前端手动加8小时来修的这属于治标不治本。正确的做法是在application.yml配置spring.jackson.time-zone: GMT8和date-format: yyyy-MM-dd HH:mm:ss从源头解决问题。6.2 部署阶段高频问题上传失败、图片403、时区偏移部署到服务器后很多本地开发没问题的事会冒出来。最常见的上传失败是上传文件过大Nginx默认client_max_body_size只有1m前端传一张手机照片就超了报413错误。Nginx配置里要加client_max_body_size 20m;同时后端multipart限制也要同步调大。图片403的问题通常和MinIO的bucket权限有关。检查MinIO控制台里bucket是否设置了公开读权限如果没有公开访问http://IP:9000/bucket/xxx.jpg就会被拒绝。如果是图片能上传但URL打不开先本地执行curl -I 完整URL看返回的状态码403是权限问题404是桶名或者路径写错了。还有一个隐蔽的问题MinIO的endpoint如果写成http://localhost:9000但前端页面通过公网IP访问时生成的图片地址是localhost用户根本点不开。所以MinIO的endpoint配置要写服务器公网IP或者域名。数据库时区设置也要检查。连接串里已经有serverTimezoneAsia/Shanghai如果依然差8小时一般是MySQL自身时区问题执行SET GLOBAL time_zone 8:00;可以临时解决但最佳实践是在配置文件中固定default-time-zone 08:00。6.3 答辩加分经验如何把“亮点”讲清楚答辩时最怕的不是功能少而是“什么都做了但讲不出重点”。我总结的答辩主线是业务痛点 → 状态机设计 → 智能匹配 → 消息通知 → 安全控制 → 部署方案。每一个环节都准备一张图或一段代码作为证据。讲状态机时画出状态流转图解释为什么把失物和招领拆成两张表为什么认领申请要单独建表。讲智能匹配时先用LIKE方案演示再提全文索引或标签匹配优化说明你考虑过数据量增长后的方案演进。讲跨平台时强调“前后端分离同一套API服务多端”最好现场展示手机浏览器访问和PC访问的效果。讲SpringBoot原理时把自动装配条件注解的链路说清楚EnableAutoConfiguration加载哪些自动配置类什么时候生效什么时候通过ConditionalOnMissingBean让位于用户自定义Bean。再补一个容易被忽略的小细节给项目写一个README.md把启动步骤、配置说明、默认账号写清楚。答辩时老师大概率会问“这个系统要跑起来需要哪些环境”如果你能条理清晰地回答印象分会加不少。最后分享一个小习惯做这类管理系统的毕设不要急着写代码先用一天时间把状态机画出来、把表结构定下来再动手。失物招领系统的核心不是增删改查而是“认领闭环”——丢东西的同学提交了信息捡到东西的同学也提交了信息两边能不能对得上、对上了之后怎么安全认领这才是系统存在的价值。把匹配、通知、认领确认这几个环节做扎实哪怕界面朴素一点答辩时都能讲出真东西。希望这篇拆解能帮正在做SpringBoot毕设的同学少走几个坑。
