基于Spring Boot的校园失物招领系统设计与实现全解析

我调试了三天把去年一个学弟送的校园失物招领系统毕设源码完整跑通之后忽然觉得这套东西值得好好写一篇。不是因为它用了多高深的技术恰恰相反它把基于Web的信息管理系统该有的那套骨架用最直接的方式串起来了——用户发布失物、发布拾物、模糊搜索匹配、认领审核、后台管理。这几乎是Java Web毕设里最典型的题目之一网上虽然一堆模板但真正能讲清楚设计思路、能让你拿着源码应付答辩的不多。这篇就围绕这套《基于Web的校园失物招领系统的设计与实现》源码把选题逻辑、技术选型、数据库设计、核心代码逻辑、部署运行、答辩亮点全部拆开讲。不管你是还没定题的大三学生还是已经下载了源码但跑不起来的大四狗这篇文章都能帮你少走弯路。1. 从丢校园卡到毕设选题为什么失物招领值得做成Web系统1.1 先聊聊校园里那个最真实的痛点校园里丢东西这件事频率高到什么程度我当年在学校后勤信息中心帮忙的时候光是学生卡一个品类每个月登记的就超过两百张。钥匙、耳机、课本、保温杯、雨伞、书包什么都能丢什么都被捡过。但问题在于捡到东西的人不知道该交给谁丢东西的人不知道该去哪里问两拨人都在各自的信息孤岛里打转。传统的校园失物招领一般靠三样东西教学楼一楼的公告栏、食堂门口的纸质登记本、辅导员班群里的转发。纸质登记本的问题是信息无法搜索翻一百条记录才能找到一条接近的公告栏的问题是时效性差贴上去一周没人看班群转发的问题是覆盖面窄发出去就沉底了。这个场景映射到系统设计上就是一个典型的多角色、多状态、强时效性的信息管理问题普通学生需要发布和查询管理员需要审核和线下流转物品信息存在丢失中—已找到—已认领—已归档的状态变化。它天然适合用Web系统来解决因为它需要的不是高并发不是复杂算法而是清晰的信息结构加好用的交互流程。1.2 为什么这个题目适合当毕设很多同学选毕设题目要么选得太空比如智能推荐系统最后做出来就是个排序列表要么选得太重比如基于深度学习的XX识别系统模型还没跑通就快答辩了。失物招领这个题目最大的优势在于它的需求边界非常清晰技术栈可以自由控制难度。你说它简单那可以做成一个纯JSPServlet的CRUD项目你说它复杂那可以加入图片识别、相似度匹配、短信通知、微信小程序端。这一个题目能从专科做到研究生选哪个技术难度取决于你的水平但需求本身是站得住的——它是真实的、有意义的、能讲清楚业务逻辑的。再从答辩的角度看失物招领系统的每个功能模块都能和课程知识对应上数据库范式设计、事务管理、文件上传、会话跟踪、权限控制、模糊查询优化这些都是评委老师喜欢追问的点你有得讲不会一问三不知。1.3 这套源码到底包含什么我在整理源码的时候把它拆成了四个部分方便对照阅读后端代码Spring Boot框架Java语言实现Maven管理依赖内置Tomcat。前端页面Thymeleaf模板引擎加原生HTML/CSS/JavaScript/Layui。数据库脚本MySQL建库建表语句以及测试数据。文档说明需求分析、ER图、数据库设计表、操作说明这套源码里都有。这些模块组合起来就是一个标准的学习型Spring Boot项目不花哨不搞前后端分离那套复杂工程结构但MVC分层、DAO层、Service层、Controller层全都有非常适合作为毕设源码学习和二次开发。2. 技术选型认清基于Web背后的三条路线2.1 技术方案对比别一上来就选最难的凡是标题带基于Web的毕设技术路线无非三条第一条路线纯JSP/Servlet JDBC。这是最老派的做法适合基础薄弱的同学。它的特点是代码冗余度高一个页面要写一堆Java片段但好处是每一步都看得见——你自己的请求自己处理自己的数据自己查。如果学校要求你展示扎实的Java基础这条路也不是不行但做出来的系统普遍比较粗糙前端和逻辑耦合严重。第二条路线SSM框架整合Spring SpringMVC MyBatis。这是前几年的主流配置多XML文件一大堆适合用来体现框架整合能力。但说句实话SSM现在教得少企业用得也少了新项目基本直接上Spring Boot。这个方案的优势是能写进简历撑场面劣势是学习成本高调试起来烦。第三条路线Spring Boot MyBatis Thymeleaf。这是目前最合理的毕设默认方案。Spring Boot把繁琐的配置自动化了内嵌Tomcat跑main方法就能启动MyBatis用注解或XML写SQL数据库操作清晰可控Thymeleaf服务端渲染不用考虑跨域和前端构建那套问题。我打包分享的这套源码走的就是第三条路线。核心逻辑是这样Spring Boot 2.x做应用框架MyBatis做持久层MySQL存数据Thymeleaf做页面渲染前端UI用Layui——一个很轻量的国产UI框架分页表格、弹窗、表单样式都有现成组件对不擅长写CSS的同学是真正的救星。2.2 开发环境和依赖清单如果你要跑这套源码先把环境对齐不然光报错就能折腾一整天。我的建议配置如下跟源码完全兼容JDK 1.88u201以上版本Spring Boot 2.x对JDK版本有硬性要求Maven 3.6配置好阿里云镜像不然下载依赖能等到怀疑人生MySQL 5.78.0也能用但要注意驱动配置和时区设置IDEA 2020及以上社区版就够用不需要旗舰版Navicat或DataGrip数据库连接工具可视化操作太香了核心依赖我列一下方便你检查pom.xml有没有问题spring-boot-starter-webWeb基础依赖集成了Tomcat和SpringMVCmybatis-spring-boot-starter 2.1.xMyBatis与Spring Boot的整合包mysql-connector-java 8.0.xMySQL驱动lombok减少实体类Getter/Setter代码一定要安装Lombok插件踩坑重灾区spring-boot-starter-thymeleaf模板引擎spring-boot-starter-validation参数校验2.3 为什么不用前后端分离方案这里多说一句我在群里经常被问为什么不用VueSpring Boot前后端分离。前后端分离确实是企业主流但对毕设来说它不是最优解——因为你要交的是一个系统不是两个工程。前后端分离意味着你要维护两个端还要解决跨域配置、Token鉴权、前端打包部署那一堆问题。你想想你的毕设文档里要写前端部署在Node环境后端部署在服务器两个启动命令一个没搞明白就前后端连不上废掉一个周末。用服务端渲染启动一个工程打开浏览器就能访问演示的时候也没有那么多意外。当然如果你已经把前后端分离玩得很熟了想用VueElementUI做前端那也是可以的。但如果你是为了求稳求过那Thymeleaf方案绝对是最省心的。这套源码选的就是务实路线一切为了能跑、能演示、能讲清楚。3. 系统功能拆解用户端和管理员端各需要什么3.1 两类角色两种权限边界失物招领系统的用户模型很清晰就两种普通学生用户和管理员。这里不搞丢失者和拾取者分开注册那套因为一个人今天丢了书明天可能就捡到别人的耳机角色的状态是动态的不好固化。普通用户的核心诉求是发布信息、搜索信息、管理自己的信息。管理员的核心诉求是审核信息、处理认领、维护公告、数据统计。权限控制这块源码里用了Spring Boot的拦截器HandlerInterceptor来实现。规则很简单未登录用户只能浏览公开的失物和拾物列表点击发布或认领时会被拦截到登录页管理员路径下所有请求都会检查当前session里的role字段不是管理员直接跳转404。没上Shiro或者Spring Security那套重型安全框架因为对这种业务体量来说没必要反而增加理解难度。3.2 用户端功能清单与操作流程用户端的功能我整理成了一张表对照着你用系统走一遍就明白了功能模块具体功能操作方式失物发布填写丢失物品的名称、类别、丢失地点、丢失时间、详细描述、联系方式、图片提交后状态为审核中管理员通过后变为招领中拾物发布填写拾到物品的名称、类别、拾到地点、拾到时间、详细描述、图片提交后状态为待认领管理员可调整失物搜索按关键词搜索标题和描述支持分类筛选模糊匹配不区分大小写认领申请对某条失物/拾物信息发起认领填写物品特征证明提交后进入认领审核中状态个人中心查看自己发布的信息列表、认领记录、消息通知可修改/删除未审核的信息收藏功能收藏感兴趣的信息方便后续跟踪列表页点击收藏图标最核心的交互流程是这样一个丢—捡—还闭环用户A丢了手机发布失物用户B捡到手机发布拾物系统根据关键词推荐匹配A或B双方看到彼此的信息A对B的拾物信息发起认领申请A上传证明资料管理员审核确认线下完成交接B确认物品已归还信息状态变为已认领。如果直接让A联系B或者B联系A系统就不需要审核了容易产生纠纷。所以中间必须有一个管理员节点这是业务合理性在设计上的体现也是答辩时能讲的亮点。3.3 管理员端功能清单管理员的后台功能更侧重管理和统计失物信息管理查看所有状态的信息审核通过/驳回修改和删除。拾物信息管理处理拾物的上架、下架、标记已归还。认领审核管理查看所有认领申请和凭证信息通过或驳回。公告管理发布系统公告用于通知重要事件。用户管理查看已注册用户禁用/启用账号。数据看板统计各类物品的丢失/找回数量用简单柱状图展示用ECharts实现的。为什么管理员要处理认领审核说白了就是背书。线上系统解决了信息匹配的问题但线下交易核验还是需要人工介入。这套系统的设计理念就是这个——线上撮合线下核验管理员作为信任锚点。4. 数据库设计五张核心表的长这样4.1 实体关系梳理数据库设计是访问答辩老师最喜欢问的部分也是最容易翻车的部分。这套源码的表结构不复杂一共五张表但每一张都能讲出设计理由用户表t_user存储学生用户和管理员的基本信息。失物表t_lost存储丢失物品的信息关联用户ID。拾物表t_found存储拾到物品的信息关联用户ID。认领记录表t_claim存储每次认领申请的状态流转记录。站内消息表t_message系统通知和个人消息。为什么失物和拾物要分两张表合在一起不好吗这是很多同学会忽略的设计点。合在一起当然能做但失物和拾物在业务属性上有差异失物有丢失地点拾物有拾取地点失物的流程终点是我已找到拾物的流程终点是已归还从统计口径上看两者也是独立的维度什么最容易丢、什么地方最常捡到东西。分表的设计更贴合业务语义SQL查询也更清晰。4.2 核心表结构与字段说明以拾物表为例建表SQL大概是这样的CREATE TABLE t_found ( id int(11) NOT NULL AUTO_INCREMENT COMMENT 主键ID, user_id int(11) NOT NULL COMMENT 发布人用户ID, title varchar(100) NOT NULL COMMENT 物品标题, category varchar(50) DEFAULT NULL COMMENT 物品分类, place varchar(100) DEFAULT NULL COMMENT 拾取地点, pick_time datetime DEFAULT NULL COMMENT 拾取时间, description text COMMENT 详细描述, image varchar(255) DEFAULT NULL COMMENT 物品图片URL, contact varchar(50) DEFAULT NULL COMMENT 联系电话, status tinyint(1) NOT NULL DEFAULT 0 COMMENT 状态0待审核1已发布2认领中3已找回/已归还4已下架, view_count int(11) NOT NULL DEFAULT 0 COMMENT 浏览次数, create_time datetime NOT NULL COMMENT 发布时间, update_time datetime DEFAULT NULL COMMENT 更新时间, PRIMARY KEY (id), KEY idx_category (category), KEY idx_status (status), KEY idx_user_id (user_id) ) ENGINEInnoDB AUTO_INCREMENT1 DEFAULT CHARSETutf8mb4 COMMENT拾物信息表;注意几个设计上的细节字段类型上描述用了text而不是varchar因为物品描述可能超过255字用varchar(255)硬存就会截断。中文场景下表字符集用utf8mb4不是utf8因为utf8在MySQL里最多支持3字节字符一些特殊符号和生僻字会存不进去。状态字段用tinyint(1)配合注释而不是直接存字符串改动代码时不需要倒库。检索优化方面category和status是高频查询条件都建了普通索引user_id是关联查询的核心也建了索引。这套表在设计阶段就规划好了索引不是后面发现慢查询才补的。4.3 状态流转与数据一致性所有业务系统的核心都藏在状态流转里。失物和拾物模块的状态设计是待审核 → 已发布 → 认领中 → 已找回/已归还 → 已下架每条状态变更都由Service层的方法来保证。以拾物为例在FoundService里是这样处理的public boolean handleClaim(Long foundId, Integer fromStatus, Integer toStatus) { Found found foundMapper.selectById(foundId); if (found null) { return false; } // 只有当前状态等于预期状态时才允许流转防止并发下状态错乱 if (!found.getStatus().equals(fromStatus)) { return false; } found.setStatus(toStatus); found.setUpdateTime(new Date()); return foundMapper.updateById(found) 0; }这种期望状态校验的做法是对并发安全很有用的。设想一下两个认领申请同时通过审核如果没有状态校验status字段会被后提交的覆盖物品就被认领两次了。加了校验后第一次更新把状态从2变成3第二次更新时发现当前状态已经不是2直接返回false从业务层防止了数据错乱。4.4 认领记录表的特殊设计认领记录表承载了最重要的审核链路字段包括认领人ID、物品ID可能是失物也可能是拾物、type字段标记认领的是哪类物品、认领说明、证明材料URL、审核状态、审核意见、创建时间、审核时间。它和物品表的关系不是简单的外键关联而是一种业务事件表的概念——每次认领都是一条独立事件可以追溯、可以驳回、可以再次申请。这比直接在物品表上加一个认领人ID字段要规范得多因为一个物品可能被多个人发起认领你得保留每一次的历史记录。5. 核心功能实现搜索、匹配、认领的代码逻辑5.1 模糊搜索的实现与优化失物招领系统最常用的操作就是搜索。用户会搜校园卡钱包黑色键盘你要做的是在title、description这两个字段里做模糊匹配同时支持分类筛选。源码里MyBatis的SQL是这样写的select idsearchFound resultTypecom.example.lostfound.entity.Found SELECT * FROM t_found where if testkeyword ! null and keyword ! AND (title LIKE CONCAT(%, #{keyword}, %) OR description LIKE CONCAT(%, #{keyword}, %)) /if if testcategory ! null and category ! AND category #{category} /if AND status ! 4 !-- 排除已下架的记录 -- /where ORDER BY create_time DESC LIMIT #{offset}, #{pageSize} /select这里用where标签而不是直接拼WHERE 11是为了让MyBatis自动处理多余的AND。这个点很基础但是是加分项——答辩时老师说你为什么不用WHERE 11你就能解释为什么where标签更优雅。关于LIKE查询必须知道它走不了索引、性能一般这个事实。但就校园失物招领这个规模——几千条数据撑死了——完全够用不需要引入Elasticsearch或者全文索引。我做毕设指导时见过很多同学为了几万条数据去上复杂中间件属实没必要正确做法是评估数据量级再决定技术方案。5.2 双向匹配推荐是怎么写的这套系统里有一个比较讨巧的功能用户发布一条失物信息后系统会去t_found表里找捡到了类似物品的记录推荐给他。反向也一样发布拾物时推荐可能丢失了它的失物信息。这个匹配最简单有效的实现方式是基于类别的匹配加关键词重合度。不是上来就搞词向量、倒排索引这些东西而是先把同分类的物品筛出来再做关键词打分public ListFound matchRecommendations(Lost lost) { // 第一步按分类粗筛 ListFound candidates foundMapper.selectByCategory(lost.getCategory()); // 第二步计算关键词重合度 String[] keywords lost.getTitle().replaceAll(\\W, ).split( ); return candidates.stream() .filter(found - containsAnyKeyword(found.getTitle() found.getDescription(), keywords)) .sorted((a, b) - score(b) - score(a)) .limit(5) .collect(Collectors.toList()); }这个匹配逻辑是规则引擎的思路没有用复杂的相似度算法。如果对效果有要求可以把containsAnyKeyword升级成SimilarityUtils计算余弦相似度或者用jieba分词之后算TF-IDF权重。但作为毕设规则模型反而更容易解释清楚也更容易在答辩时答上问。5.3 认领审核链路和防恶意认领认领流程是系统的安全敏感点。源码里的认领状态机是待审核、已通过、已驳回、已完成四态。发起认领时要填写联系方式、详细描述还必须要上传一张图片作为佐证。这个佐证图片设计有讲究一方面它能有效过滤恶意认领——想冒领的人至少得编一个看起来合理的说法、准备一张图另一方面也为管理员的审核提供了判断依据。审核页面会把认领人信息、物品原发布者的描述、认领人提供的描述并排展示管理员一眼能看出描述是否吻合。防恶意认领还有一个细节同一个用户对同一个物品只能发起一次认领不能重复申请。这个约束在ClaimService里做了唯一性校验if (claimMapper.existsByUserAndItem(userId, lostId, type) 0) { throw new ServiceException(您已对该物品发起过认领申请请等待管理员处理); }5.4 图片上传与文件存储本地图片上传是最容易被忽略又最容易出坑的环节。源码里的实现是用MultipartFile接收文件按照yyyyMMddHHmmss_随机数的格式重命名存储到本地的/upload/目录再把相对路径存入数据库的image字段。需要注意以下几个坑第一重命名必须用时间戳加UUID或随机数不能用用户原始文件名否则中文文件名、重复文件名都会出问题。第二存储路径必须是绝对路径不能是相对路径否则部署到服务器后一定找不到文件。第三访问图片的映射要单独配置Configuration public class WebMvcConfig implements WebMvcConfigurer { Override public void addResourceHandlers(ResourceHandlerRegistry registry) { String uploadPath System.getProperty(user.dir) File.separator upload File.separator; registry.addResourceHandler(/upload/**) .addResourceLocations(file: uploadPath); } }如果你的系统部署到服务器上考虑用对象存储服务或者把上传目录挂到独立数据盘但本地文件存储对毕设来说完全够用。6. 前端页面与交互Layui如何简化你的前端工作量6.1 页面架构和路由划分这套系统的前端页面按照用户端和管理端分成两个布局。用户端页面包括首页、失物列表、拾物列表、失物详情、拾物详情、发布信息、个人中心、消息列表管理端页面包括数据看板、失物管理、拾物管理、认领管理、用户管理、公告管理。路由层面通过Controller返回视图名比如/found/list返回Thymeleaf模板found/list.html。没有用RESTful接口那套因为服务端渲染天然就是页面导向的。登录拦截器在WebMvcConfig里注册排除掉静态资源和登录注册接口。6.2 列表页的分页与筛选列表页用的是Layui的table模块配合后端分页接口。用户选分类、输关键词、点查询前端把参数通过table.reload传给后端后端返回JSON格式的分页数据。浏览器端就有表格、分页条、操作列。这里涉及一个知识点Thymeleaf渲染首屏后续的动态操作走Ajax拿JSON两者混着用。这是服务端渲染项目非常常见的模式理解它你就理解了这套系统的数据流动方式——首屏数据由模板引擎注入交互数据由接口返回。6.3 详情页的两个关键入口详情页是核心转化页面用户在这里决定是否发起认领。所以页面设计上把物品信息放在顶部包括图片轮播、状态标签、发布时间、浏览数中间是发布人填写的详细描述底部是操作区——如果当前物品是招领中或认领中登录用户可以看到发起认领按钮点了之后弹窗表单上传证明。展示联系的策略是查看完整联系方式需要登录并且只有在发起认领申请后申请人和发布人之间才会互相看到真实的手机号。这个设计减少了信息被爬虫抓取和骚扰电话的风险在答辩时可以作为一个隐私保护的亮点来讲。7. 环境配置与部署运行从零跑通整个项目7.1 本地运行步骤这部分是踩坑最密集的环节。我按顺序把步骤列出来每一条都是血泪总结导入数据库用Navicat新建数据库lostfound字符集选utf8mb4排序规则选utf8mb4_general_ci然后导入sql目录下的lostfound.sql脚本。导入后检查一下表是否齐全——常见问题是因为MySQL版本差异导致某些字段类型不兼容导入报错。修改配置文件打开src/main/resources/application.yml把url改成jdbc:mysql://localhost:3306/lostfound?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/ShanghaiallowPublicKeyRetrievaltrue把用户名和密码改成你自己的。这里最容易出错的是时区参数serverTimezone不加MySQL 8.0一定报时区错误。配置MavenIDEA里配置好Maven仓库建议用阿里云镜像不然下载Spring Boot 2.7的依赖可能要半小时以上。检查一下.m2/settings.xml的文件。启动项目运行LostfoundApplication的main方法看到Spring Boot启动日志监听8080端口。访问系统浏览器打开http://localhost:8080。系统内置了一个管理员账号admin/admin123还有一个测试用户test/123456直接登录管理后台测试功能。7.2 常见报错和解决方法这堆报错我基本全遇到过汇总成一张表报错现象根本原因解决方案Access denied for user rootlocalhost数据库密码错误或权限不足修改application.yml的账号密码确认能正常连接Unknown database lostfound数据库没有导入成功重新执行SQL脚本Server returns invalid timezoneMySQL时区未设置JDBC连接串加serverTimezoneAsia/Shanghai页面显示Whitelabel Error Page后端接口500看IDEA控制台日志通常是SQL语句或参数错误静态资源404图片不显示上传路径配置不对确认WebMvcConfig的映射路径与磁盘路径一致java.lang.IllegalStateException: Cannot load driver class没引入MySQL驱动检查pom.xml是否有mysql-connector-java依赖控制台报Failed to configure a DataSource启动时没读到数据库配置检查application.yml是否正确放置在src/main/resources下7.3 怎么打包部署到服务器如果你想远程演示或者部署到云服务器用Maven的package命令打一个jar包mvn clean package -DskipTests然后上传到服务器用java -jar lostfound-0.0.1-SNAPSHOT.jar --server.port8080运行。别忘了服务器安全组放行8080端口数据库要改成服务器本地的MySQL地址。有公网IP的话配合Nginx反向代理可以把前端域名和后端端口统一起来但毕设演示直接用IP加端口就可以了。8. 从及格到加分给毕设答辩准备的几个加分点8.1 可以在哪几个方向做深度扩展如果你的目标不只是通过而是优秀这套源码下面这些扩展空间非常加分数据可视化已有的简单柱状图可以升级成ECharts的折线、饼图、地图展示不同时间段物品丢失数量的趋势、各类物品占比、各地点丢失热度。这个方向技术难度不高但视觉效果好评委看着舒服。消息推送用户发布的失物信息一旦出现匹配度高的拾物系统立刻给用户发邮件或短信通知。Spring Boot整合JavaMailSender实现邮件发送很简单能让你从被动查询变成主动送达业务价值提升一大截。物品识别如果你是计算机视觉方向的学生可以在拾物发布时加一个基于深度学习的物品分类功能用户上传照片系统自动识别物品类别并填充。答辩效果直接拉满因为它是真正用到了AI。校园卡优化针对校园卡这种有唯一标识的物品类型单独做一个快捷通道——只需要输入卡号就能查询是否有被捡到的记录复杂度低但实用性强。小程序端微信小程序调用这套系统的后端接口做一套移动端页面。现在学生丢东西第一反应是看手机小程序端的价值比电脑端大得多。如果前端基础还行这个方向是最能体现工程能力的。8.2 答辩时可能会被问到的问题根据往年经验老师对这类系统的追问重点集中在这几个方向你的系统安全性如何保证答密码使用MD5加密存储、登录拦截器控制访问权限、管理员操作有日志记录。这里如果深挖MD5不够安全可以提前准备升级成BCrypt加密的代码。如果数据量大了怎么办答当前业务体量下MySQL单表足够如果量大可以考虑分表分库、加Redis缓存、引入Elasticsearch做全文检索。你要让老师知道你清楚这几个方向只是当前规模不需要用。状态流转为什么这样设计答因为失物招领的核心是信息撮合加线下核验状态流转反映了物品从丢失到归还的完整生命周期每个状态变更都有管理员审核参与保证流程可追溯。你的认领审核是怎么防止冒领的答三重机制——描述吻合度对比、佐证图片审核、管理员线下核验。这套流程对应了系统的可信设计。8.3 源码使用的最后几点建议这个源码我建议你按三条线去读先跑起来再改起来最后讲出来。第一步跑起来搞定环境问题对照前文的部署步骤把系统完整运行一遍。第二步改起来挑一个你最想实现的功能去改代码——哪怕只是改一个栏目加深对代码结构的理解。第三步讲出来写一份自己的讲解稿把为什么这么设计的逻辑自己复述一遍。最后还有一个实在的建议不要直接拿这个系统原样交上去。哪怕只是改个系统名称、换一套颜色方案、加一个功能页面你也能在答辩时理直气壮地说这是我独立完成的设计与实现。技术是手段讲清楚它、复现它、改进它这个过程中学到的东西才是你做毕设真正拿到的回报。