基于SpringBoot的高校失物招领管理系统设计与实现

失物招领管理系统这个题目，在计算机毕业设计里属于典型的“看着简单、做起来全是坑”的项目。每年都有不少同学选基于SpringBoot的高校失物招领管理系统，最后却把课程设计的CRUD直接搬来交差——这其实是把题目做小了。我这两年帮人审过几十个类似项目，今天把从选题、设计到落地的完整思路一次性拆开讲，适合正在做毕设的同学，也适合刚接触SpringBoot、想拿一个较完整项目练手的人。

高校场景下的失物招领，和大众点评、电商系统最大的不同在于业务闭环：东西丢了有人发布、东西捡到有人登记、两边如何匹配、匹配成功后怎么认领、认领后怎么归档。如果只做“发布+展示”两个接口，那系统就只是个公告板，答辩时很难拿出像样的亮点。真正值钱的部分在于“智能匹配”和“认领状态流转”，这两块才是能讲技术深度的位置。下面我会从需求拆解、技术选型、数据库设计、核心功能实现到部署排错，把整套方案按我自己实际开发的顺序讲清楚。

1. 项目定位与需求拆解：这题不只是做个CRUD

1.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浏览器、手机浏览器、甚至微信小程序共同访问。

我建议的这套技术栈，属于性价比最高、代码量可控、答辩有得讲的一种组合：

选这套组合有个隐藏逻辑：每一项都能在答辩时讲清楚“为什么不用另一个方案”。比如为什么用MyBatis-Plus而不是JPA？因为管理系统的查询条件多且动态，MyBatis系的SQL可控性更强；为什么图片不直接传服务器本地？因为本地磁盘在打包部署时容易丢，迁移麻烦，接入MinIO能体现你对生产环境的理解。

2.2 跨平台方案：同一套API服务多个端

跨平台的核心不是写多套代码，而是保证后端API的前后端分离架构。SpringBoot只提供JSON接口，不关心请求来自PC浏览器、手机Safari还是微信小程序。这样前端可以单独部署，后端部署在服务器上，通过Nginx做反向代理。如果后面想扩展小程序端，只需要新增一个小程序前端项目，复用同一套接口，业务代码一行不用动。

实际操作时，有几件事必须提前处理：跨域配置、Token校验、响应体结构统一。跨域不配置好，前端dev环境的请求会被浏览器拦截；响应体不统一，前端每个接口都要单独判断错误码，代码会写得很乱。我建议后端统一返回Result<T>结构，包含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张表，我把核心表和关键字段列出来，可以直接照着建：

这里有个很容易踩坑的设计决策：为什么不把“丢失物品”和“招领物品”合成一张表？我试过合成一张表加一个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的历史记录并通知A；A看到通知后进入招领详情页提交认领申请，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绑定。每个用户建立连接后，在服务端维护一个ConcurrentHashMap<String, 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.x：

<dependency> <groupId>io.jsonwebtoken</groupId> <artifactId>jjwt-api</artifactId> <version>0.11.5</version> </dependency> <dependency> <groupId>io.jsonwebtoken</groupId> <artifactId>jjwt-impl</artifactId> <version>0.11.5</version> <scope>runtime</scope> </dependency> <dependency> <groupId>io.jsonwebtoken</groupId> <artifactId>jjwt-jackson</artifactId> <version>0.11.5</version> <scope>runtime</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?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/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: GMT+8 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: GMT+8和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或者域名。

数据库时区设置也要检查。连接串里已经有serverTimezone=Asia/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毕设的同学少走几个坑。