SpringBoot宠物领养平台毕业设计：从数据库设计到部署答辩全攻略

想做一个宠物领养类的全栈系统，用SpringBoot做后端，这个选择在毕业设计里算是既稳又容易出亮点的方向。流浪动物救助与领养平台，本质上不是普通的CRUD，它要同时处理“动物信息管理”“用户申请审核”“救助与收容记录”“回访追踪”这几条业务线，做得好不好，直接决定答辩时能不能把“业务复杂度”讲清楚。这篇就围绕这个项目的设计与实现，把我自己实际开发过程中认为最值得说的细节、踩过的坑和可以放心的加分点，完整梳理一遍。

1. 项目整体设计与技术选型思路拆解

1.1 为什么选SpringBoot而不是老一套的Servlet/JSP

很多同学在选技术栈的时候会纠结：学校里学过SSH、SSM，也写过Servlet，为什么毕业设计非要用SpringBoot？我的看法是，SpringBoot不是炫技，而是解决实际开发效率问题。传统SSM你要手动配置web.xml、springmvc.xml、mybatis-config.xml，光环境搭建就能耗掉两三天，而且配置文件一多，新手根本分不清是哪里写错。SpringBoot通过自动配置把大部分模板配置干掉，内嵌Tomcat一键启动，你只需要关注业务代码本身。

对于宠物领养管理系统这类业务，核心难点不在“怎么配置框架”，而在“业务状态怎么流转、数据怎么组织、前后端怎么配合”。SpringBoot能让你把时间花在刀刃上，而不是浪费在配置地狱里。而且Spring Boot 3.x虽然已经支持JDK 17，但如果你用的是学校机房的老环境，稳妥起见选Spring Boot 2.7.x + JDK 8，兼容性最好，部署也省心。我实际做了两个版本，最终交付用的还是2.7.x，原因很简单：学校评审环境、服务器环境基本都是JDK 8，没必要在版本上给自己找麻烦。

1.2 整体架构与技术栈如何分配

一个完整的宠物领养平台，我建议按“前后端分离”来设计，但不一定非要微服务。毕设项目的体量，单体应用完全够用，微服务反而会把简单问题复杂化。

后端核心组件：

• SpringBoot：项目骨架与依赖管理
• MyBatis-Plus：ORM框架，内置分页、逻辑删除、代码生成器，能省大量重复的Mapper操作
• MySQL：存储业务数据，5.7或8.0均可
• Redis：做缓存、验证码存储、高频数据的读写，加分项明显
• Spring Security或Sa-Token：认证与权限控制，二选一即可
• Hutool：工具类库，处理验证码生成、日期转换、随机数等小功能

前端我选了Vue 3 + Element Plus，配合Axios请求后端接口。如果你的前端基础一般，用Thymeleaf模板引擎也能实现，但前后端分离的项目在答辩时更聊得开，因为可以讲“接口设计”“跨域处理”“异步交互”这些点。

这套技术栈选型的核心逻辑就一句话：每一层都能讲出“为什么”，同时每一层都足够成熟，不会在开发中突然卡住。Redis不是必须的，但加上了之后，业务里“首页热点动物列表”“验证码存储”这类场景就有了实际意义，而不是为了加而加。

2. 核心业务模块梳理与数据库设计细节

2.1 围绕“救助-收容-领养”的主线拆功能

这个项目有一个天然的业务主线：流浪动物被发现 → 救助人登记或提交求助 → 平台收容建档 → 公众浏览与申请领养 → 平台审核与回访。所有功能模块都围绕这条主线展开，这也是和普通信息管理系统的本质区别。

用户端功能基本是这些：

• 注册登录、个人信息维护
• 浏览流浪动物列表、查看详情
• 在线提交领养申请、上传领养承诺信息
• 提交流浪动物救助登记
• 收藏关注、留言咨询
• 查看申请进度与回访记录

管理端功能要对应起来：

• 动物档案管理，包括新增、修改、状态变更、下架
• 领养申请审核，包括资料初审、协议确认、回访记录
• 救助登记处理，将救助信息转为正式收容档案
• 公告发布与管理
• 基础数据统计，比如分类统计、申请转化率

这里有一个很关键的设计点：领养不是简单“点击申请，管理员通过”就完了，它需要多状态流转。我在最初的数据库设计里只给动物表留了一个status字段，后来发现根本不够用。实际业务里，“动物状态”和“领养申请状态”是两条独立的状态线，必须分开管理，否则审核到哪一步、回访是否完成，全都乱套了。

2.2 数据库表设计与状态机流转

数据库表我建议拆成这几张核心表：

• 用户表：用户ID、用户名、密码（加密存储）、手机号、角色（普通用户/管理员）、头像、领养次数等
• 动物表：动物ID、名称、品种、毛色、性别、绝育状态、疫苗状态、健康描述、图片、收容日期、来源（救助/社会送养）、状态
• 领养申请表：申请ID、用户ID、动物ID、申请时间、个人情况描述、居住环境、养宠经验、审批状态、审批意见
• 救助登记表：登记ID、上报人姓名、联系电话、发现地点、动物状况描述、图片、处理状态
• 回访记录表：记录ID、申请ID、回访时间、回访人、回访内容、结果
• 公告表、留言表、收藏表：常规设计即可

动物表的状态我用了枚举值存储：

• 待审核：刚提交或救助登记转过来的
• 待领养：审核通过，对外开放申请
• 已预约：有人提交申请，初筛通过
• 已领养：完成领养流程
• 已下架：因故下架

领养申请表的状态是另一条线：

• 待初审：用户提交申请，管理员还没看
• 初审通过/初审驳回：基础资料是否合格
• 待签协议：初审通过后，线下或线上确认领养协议
• 完成：协议签完，动物正式交接
• 回访中：交接后需要做定期回访
• 已结束：回访无异常，流程终止

这两条状态线必须同步更新，但又是独立存储。比如一个动物被申请领养，动物表状态改为“已预约”，同时申请表的记录变为“初审通过”，这两步操作我在Service层统一放到一个事务里。这个设计在答辩时非常加分，因为不是每个人都能说清楚“状态与状态之间的联动事务”。

3. 关键功能实现与实操要点

3.1 用户注册登录与权限控制的实现方式

登录这块我用的是Sa-Token，相比Spring Security的配置复杂度，Sa-Token在毕设项目里更友好，学习成本低，代码写起来也直观。核心逻辑很简单：用户输入账号密码，后端校验通过后用Sa-Token签发一个登录凭证，前端后续请求都带着这个凭证访问受保护接口。

密码存储一定要用加密算法，我用的是BCrypt。千万不能明文存密码，这个在答辩时也是考察点。

// 用户注册时加密密码 String encodedPassword = BCrypt.hashpw(user.getPassword(), BCrypt.gensalt()); user.setPassword(encodedPassword);

登录接口的大致流程是：接收账号密码 → 查库对比密码 → 成功则登录并返回token → 失败返回统一错误码。这里注意一个细节，项目里凡是涉及“统一返回格式”的，我提前封装了一个结果类Result，成功返回data，失败返回msg和code，前端拿到之后统一处理。这个习惯真的很重要，后期联调会省掉大量扯皮。

权限控制就是拦截器或过滤器的事。没登录只能访问浏览接口，管理员接口需要校验角色标识。我做了一个简单的注解式权限控制，给管理端接口加上特定注解，拦截器统一校验，代码很干净。

3.2 领养申请审核流程的代码实现

领养审核是整个系统里最值得讲的部分。我先说说审核逻辑的设计思路，再贴关键代码。

用户提交申请时，后端要做三层校验：

• 申请接口是否重复提交同一个动物，防止恶意刷申请
• 动物状态是否为“待领养”，只有待领养的动物才能被申请
• 用户信息是否完整，例如手机号、居住描述是否为空

@Transactional public Result applyAdopt(AdoptApplyDTO dto) { // 1. 检查动物是否存在且状态为待领养 Animal animal = animalService.getById(dto.getAnimalId()); if (animal == null || !"待领养".equals(animal.getStatus())) { return Result.error("该动物当前不可申请领养"); } // 2. 检查是否重复申请 Integer count = adoptApplyMapper.countByUserAndAnimal(dto.getUserId(), dto.getAnimalId()); if (count > 0) { return Result.error("您已申请过该动物，请勿重复申请"); } // 3. 写入申请表，初始状态：待初审 AdoptApply apply = new AdoptApply(); BeanUtils.copyProperties(dto, apply); apply.setStatus("待初审"); adoptApplyMapper.insert(apply); // 4. 动物状态改为已预约 animal.setStatus("已预约"); animalService.updateById(animal); return Result.success("申请提交成功，等待审核"); }

注意这个@Transactional，这里不是写上去好看的。步骤3和步骤4必须同时成功或同时失败，如果不是事务操作，申请记录写入了，动物状态没改成功，后面就全是脏数据。我在一开始就是忘了加事务，测试时发现偶发数据不一致，后来定位到问题才补上。这个坑相当典型。

管理员审核时同理，修改申请表状态、记录审批意见、通知用户，这些操作也建议放同一个事务里。通知这个动作我用的是站内信逻辑：申请状态变化时插入一条消息记录，用户在个人中心可以看到，不需要接短信服务。

3.3 文件上传与图片存储的处理

宠物领养系统里图片处理是绕不开的，动物照片、健康证明、救助现场图都需要上传。我前后试了两种方案，最终采用的是本地存储+访问映射的方式。

文件上传逻辑：

• 前端用Element Plus的上传组件，选择图片后通过Axios提交到后端接口
• 后端接收MultipartFile，校验文件类型和后缀
• 按日期建目录，文件名使用时间戳+随机数
• 保存后返回可访问的URL，存储到数据库

public String uploadImage(MultipartFile file) { long size = file.getSize(); if (size > 5 * 1024 * 1024) { throw new BizException("图片大小不能超过5MB"); } String originalFilename = file.getOriginalFilename(); String suffix = originalFilename.substring(originalFilename.lastIndexOf(".")); if (!Arrays.asList(".jpg", ".jpeg", ".png", ".gif").contains(suffix.toLowerCase())) { throw new BizException("仅支持jpg、png、gif格式的图片"); } // 按日期生成目录，避免文件全堆在根目录 String datePath = new SimpleDateFormat("yyyyMMdd").format(new Date()); File dir = new File(uploadPath + datePath); if (!dir.exists()) { dir.mkdirs(); } String fileName = System.currentTimeMillis() + "_" + RandomUtil.randomString(5) + suffix; file.transferTo(new File(dir.getAbsolutePath() + File.separator + fileName)); return "/uploads/" + datePath + "/" + fileName; }

这里有两个容易被忽视的细节。第一是文件大小和格式校验，必须做在前端也能做在后端，但后端是必须的，因为别人可以用Postman直接调接口绕过前端限制。第二是映射配置，SpringBoot默认只处理static目录下的静态资源，上传目录在项目外或临时目录时，需要写一个配置类把“/uploads/**”映射到实际存储路径，否则图片永远加载不出来。

@Configuration public class WebConfig implements WebMvcConfigurer { @Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/uploads/**") .addResourceLocations("file:" + uploadPath); } }

第三个细节是我实际运维时踩过的坑：千万不能把上传目录放在target目录或者打包目录里。Maven打包时mvn clean会清空target，你测试上传的所有图片瞬间全没了。我把上传路径配置成了绝对路径，比如/user/local/pet-adoption/uploads，与项目代码分离，这样重启、重新打包都不影响历史图片。

4. 开发环境搭建与项目落地过程

4.1 从零到跑通完整项目的详细流程

很多人倒在项目起步阶段，是因为环境没理顺。这部分我把从创建到跑通的完整流程写出来，照着做基本不会卡壳。

第一步，环境准备。JDK 8、Maven 3.6+、MySQL 5.7+、Redis（如果你用了），开发工具我用的是IDEA，社区版也够用。数据库可视化工具用Navicat或者DataGrip。

第二步，创建SpringBoot项目。去Spring Initializr生成基础工程，也可以直接在IDEA里创建。依赖勾选Web、MySQL Driver、MyBatis、Lombok、Redis、Validation这些，后续缺什么自己加也行。

第三步，配置application.yml。这里面的坑最多，我把关键配置贴出来：

server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/pet_adoption?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: 你自己的密码 redis: host: localhost port: 6379 database: 0 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

有几个配置细节必须解释清楚。URL里必须加serverTimezone=Asia/Shanghai，不加会报时区错误，这是新手最常见的报错。MyBatis-Plus的逻辑删除配置，就是“逻辑删字段”和“不删字段”的全局设定，设置了之后，你调用deleteById时实际执行的是update，把deleted字段置为1。用作删动物记录非常合适，保证历史领养数据不丢。

第四步，建表。直接用SQL脚本执行创建所有表。这里我强烈建议把所有建表语句整理成一个init.sql文件，而不是在Navicat里一张一张手工建。原因有两点：一是可复现，换台电脑直接执行脚本就能重建；二是形态正规，提交资料和答辩演示时能体现出工程化意识。

第五步，编写代码。按照Controller → Service → Mapper的顺序，先把一条链路的“用户登录”跑通，再扩展其他模块。不要一次性把全部代码写完再启动调试，那样出了问题很难定位。

第六步，前端工程。Vue部分单独建工程，通过Vite启动开发服务器，端口默认5173。开发时配置代理，把 /api 开头的请求转发到后端8080，避免跨域问题。生产环境把前端打包出的dist目录扔到Nginx里，再配合后端接口就能直接对外提供服务。

4.2 接口联调与自测时要注意的细节

接口联调时最容易出问题的是数据和前端期望对不上。我自己的经验是，每个接口在写完后先自己用工具测一遍，确认返回格式统一、关键字段都有值，然后再给前端。不要觉得这个步骤浪费时间，等前端跑来跟你说“接口报错了”，你再回头排查花费的时间多得多。

Postman是必须用的。我给这个项目整理了完整的接口文档，把所有接口按模块分组，包括请求方式、路径、入参示例、出参示例。这个文档在写论文和答辩材料时直接就能当附件，非常省事。

自测时重点关注这几个接口场景：

• 注册一个普通用户，登录，修改个人信息
• 管理员新增动物信息，上传图片
• 普通用户浏览动物列表，详情页，申请领养
• 管理员初审申请、通过、完成回访
• 用户查看自己的申请记录，看到状态实时变化

把这五条业务链路完整跑通，项目的主干功能就没有大问题了。剩下的是公告、留言、收藏这些辅助功能，按类似模式实现即可。

这里还要提一个Vue3对接时的经典问题：后端接口返回的JSON字段命名，前端默认使用驼峰，而后端如果数据库字段带下划线，MyBatis-Plus默认会把下划线转驼峰，不用担心。但你如果手写SQL查询，返回的Map里字段名就是数据库原样，下划线风格，前端会比较别扭。所以我的建议是：所有DTO和VO都明确字段命名，Mapper返回实体对象，不返回Map，这样前后端联调最舒服。

5. 部署上线与常见问题排查实录

5.1 打包部署的完整操作

毕业设计到交付环节，需要把后端打成jar包、前端打成静态文件，然后一起部署到服务器。这一步没做好，演示的时候当场翻车的情况时有发生。我讲一下我自己验证过的部署路径。

项目根目录执行：

mvn clean package -DskipTests

构建成功后会生成target目录下的jar文件。然后放到服务器上，执行：

java -jar pet-adoption.jar --spring.profiles.active=prod

生产环境的配置我单独放在application-prod.yml里，数据库地址和上传路径与本地不同，用启动参数切换配置环境。这样避免把本地开发数据库密码泄露在代码里，也更符合项目部署规范。

前端部分先构建：

npm run build

生成dist目录，把这个目录里的文件部署到Nginx的html目录下。Nginx需要做一个反向代理，把/api开头的接口请求转发到后端地址：

server { listen 80; server_name 你的服务器IP; 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; } }

这个try_files配置特别重要，因为Vue是单页应用，刷新某个路由时如果Nginx没有这个配置，404直接出现。有了try_files，刷新时会把请求回落到index.html，由前端路由接管页面。

再说个部署时的安全小细节：生产环境一定要改数据库密码，不要用root弱口令，这是最低要求。然后还要记得修改所有后台管理员的初始密码。我在测试环境用的密码是123456，部署前全部换掉了。

5.2 高频故障排查速查表

开发调试和部署过程中，下面这些错误几乎百分之百会遇到。我把排查思路和解决办法整理成一张表，能少走很多弯路。

排查问题有个通用方法论：先看日志，再查网络请求，最后才怀疑代码。SpringBoot控制台每分钟都有日志，报错信息里90%都直接告诉了你原因。我见过很多同学一报错就开始逐行读代码，其实看一眼第一条异常信息，往往十秒就能定位到问题。这也是实操中非常值得培养的调试习惯。

6. 毕业设计答辩重点与系统扩展方向

6.1 答辩时的讲解逻辑和常见追问

答辩的时候，整个项目的讲解逻辑不能按照“我做了用户管理、做了动物管理”这种功能罗列式讲，而是要有主线。我自己的建议是按照业务主线来讲：流浪动物被发现→救助登记→收容建档→公开领养→审核→回访。这条线能把所有功能串成一个完整的故事，评审听着不累，也更认可你的设计能力。

这个项目在答辩时，有这几个追问基本属于必问题目：

第一个问题：为什么用Redis？这个要答得具体一点。我会说，首页的热门动物列表是高频访问数据，每次都查MySQL压力大，所以用Redis缓存，设置过期时间，管理员更新动物信息时主动删除对应缓存；登录验证码也是存Redis，设置有效期，防止验证码永久有效；如果Redis挂了，核心流程还有兜底逻辑，不会直接崩溃。

第二个问题：领养审核流程你怎么设计？这就是前面说的状态机逻辑，你把动物状态和申请状态两条线的联动关系讲清楚，再加事务保证一致性，基本就过关了。

第三个问题：如果有两个人同时申请同一只猫怎么处理？这个很有区分度。我的方案是：申请接口里先做一个条件更新操作，类似于数据库中先更新动物状态为已预约成功才继续写入申请表，利用数据库行的行级锁保证只有一个申请能成功。细节是我用MyBatis写了一个条件更新，where animalId=? and status='待领养'，如果有并发，第二个请求更新影响行数为0，直接拒绝。

第四个问题：系统的安全性怎么保证？密码BCrypt加密、登录凭证校验、管理员权限拦截、文件上传格式校验、参数校验注解，这几条挨个说一遍就很稳了。

答辩讲得好不好，不在于堆了多少新名词，而在于能不能把你写的每一行代码都讲出原因。

6.2 低成本加点“独特性”的扩展方向

毕设做完之后，如果你还有余力，我很推荐做一到两个小扩展，成本不高，但能让项目在答辩或作品集里显得更有特点。

最简单的扩展是首页增加统计面板。用Echarts画出每月救助数、领养数、动物分类占比图。后端写一个聚合SQL，前端用图表组件展示，代码量不大，但视觉效果好，汇报时冲击力强。

第二个扩展是增加定时提醒功能。领养完成后，系统需要做回访，我用SpringBoot的定时任务写了一个回访提醒：动物被领养三个月后，自动生成一条待办任务给管理员，提示进行第一次回访。这几乎不增加业务复杂度，但让系统有了“运营属性”，不再是死板的增删改查。

第三个可以考虑的扩展方向是消息通知模块。用户提交申请后，管理员审核状态发生变化，通过站内信通知用户，用户登录后未读消息有红点提醒。这个功能用一张消息表和MyBatis-Plus查询未读数就能实现。

第四个是条件搜索的优化。只靠MyBatis-Plus的QueryWrapper做简单查询是最基础的，我后来加了一个按品种、是否绝育、是否接种疫苗组合筛选的功能，看起来是简单查询，但可以和前端动态展示结合，体验会好很多。

如果你能力允许，还可以做一个移动端的适配。不一定非要微信小程序，做一个响应式页面，让手机用户可以正常浏览和申请，就已经比大部分同期项目强了。我自己是做了一个简化版的H5页面，把核心功能“浏览动物、提交申请、查看进度”搬到了移动端，代码复用后端的接口和逻辑，工作量不大，效果却很好。

再补充一个比较新的方向：使用OCR识别上传的疫苗本或体检报告。现在很多基础功能大家都在做，但“上传图片后自动提取疫苗有效期、体检结果”这类智能化功能，做成亮点项目的比例不高。借助现成的OCR接口或本地库，识别关键文字存入动物健康信息，题目和效果都能让人眼前一亮。

无论扩展哪个方向，核心思路都是一样的：不要贪多，做精一个，把这个扩展在功能、数据表、接口、前端页面完整闭环，然后拿它当你的讲解重点。

我在实际开发这个宠物领养系统的过程中，最大的体会是：很多表面看很简单的地方，真正走到细节里才会发现复杂。比如领养状态的两条线联动、数据一致性问题、文件上传路径规划、部署时的Nginx配置，单独看每一个都不是大难点，但要把这些细节全部串成一个稳定可运行的项目，靠的是工程意识和反复调试。你把你踩过的每一个坑、每一个设计和实现的原因想清楚，这个项目自然就站得住了。

最后说一个我一直保留的小技巧：项目开发过程中，把自己做过的每一个关键决策、遇到的每一个问题，都在一个文档里记录下来。到了写论文、准备答辩的时候，这个文档就是你的素材库，比临时回忆强十倍。打造一个项目并讲好它，本质上是同一件事。