基于 Spring Boot 与 Vue 3 的宠物领养管理系统设计与实现

程序员阿黄
0 阅读19分钟

基于 Spring Boot 与 Vue 3 的宠物领养管理系统设计与实现

摘 要

随着城市流浪动物数量的增长，救助站依赖人工登记与社交群扩散的送养方式，在信息透明度、审核规范性和后续跟踪方面已难以满足实际需求。本文设计并实现了一套基于 B/S 架构的宠物领养管理系统，采用 Spring Boot + Spring Data JPA 构建后端 API，Vue 3 + Element Plus 构建前端界面，MySQL 8.4（InnoDB）作为持久层，实现了宠物浏览、领养申请、管理员审核、救助站容量管理与领养回访跟踪的一体化管理。

系统在领养核心业务上给出了完整的工程化方案：审核通过操作在数据库事务内对宠物行加悲观写锁（PESSIMISTIC_WRITE），串行化并发审核请求，从机制上杜绝了同一宠物被重复领养的问题；领养申请采用四状态机管理全生命周期，审核通过时自动驳回同一宠物的其余待审申请；救助站引入容量约束，宠物入站与救助站缩容均做容量校验，形成真实业务规则；领养通过后按电话/上门两种方式登记回访，回访完成必填回访记录，形成"申请 → 审核 → 回访"的业务闭环。系统功能经 15 个服务层单元测试验证全部通过。

1 系统概述

1.1 课题背景

流浪动物救助与送养是城市治理中的常见公益场景。在传统的管理模式下，救助站送养依赖微信群、朋友圈等渠道人工扩散，存在以下问题：一是信息不透明，待领养宠物的资料散落在聊天记录中，意向领养人无法按物种、品种等条件检索；二是审核流程无序，申请与审核记录缺乏统一管理，同一宠物被多人重复申请时无法界定先后；三是后续跟踪缺失，宠物被领养后缺少回访机制，无法确认动物的生活状况；四是救助站资源无约束，接收宠物没有容量上限，站点负载失衡。

信息化管理系统将宠物档案、领养申请、审核、回访全流程线上化，是解决上述问题的直接手段。

1.2 课题意义

本课题的意义体现在三个层面：

  1. 对领养人：随时按物种、关键词检索待领养宠物，查看完整档案与所在救助站，在线提交申请并实时跟踪审核进度与回访安排；
  2. 对救助站与管理员：宠物档案、救助站容量、领养审核、回访计划集中在一个后台完成，审核结果自动联动宠物状态，数据看板提供量化统计；
  3. 对毕业设计本身：领养审核是典型的并发安全问题，本题覆盖了事务、悲观锁、状态机、容量约束、JWT 认证等后端核心知识点，以及组件化、路由守卫、状态管理等前端工程实践，技术覆盖完整且难度适中。

1.3 主要内容

本文围绕系统的分析、设计与实现展开，共分六章：

  • 第一章，绪论，介绍课题背景、意义与研究现状；
  • 第二章，系统开发环境，介绍系统采用的关键技术；
  • 第三章，需求分析，从可行性、功能需求、业务流程等方面分析系统；
  • 第四章，系统概要设计，包括系统结构、功能结构与数据库设计；
  • 第五章，系统详细设计与实现，按用户端与管理端分模块展示实现效果；
  • 第六章，系统测试，给出测试环境、用例设计与测试结果分析。

1.4 研究现状

宠物领养、动物收容类管理系统是管理信息系统的常见选题。现有方案多停留在"宠物信息展示 + 申请登记"的层面，普遍缺少三个层面的设计：一是并发安全，管理员审核与申请人重复提交在高并发下存在竞态窗口，同一宠物可能被重复审核通过；二是业务闭环缺失，多数系统到"审核通过"即止，没有领养后的回访跟踪机制；三是资源约束缺失，救助站接收宠物没有容量上限，数据模型上只是一张孤立的信息表。本系统在这三点上做了针对性设计：以悲观行锁保证审核与状态流转的原子性，以回访记录表延伸业务流程，以容量字段约束救助站的宠物容量。

2 系统开发环境

2.1 总体技术栈

系统采用前后端分离架构：

层次技术选型说明
前端Vue 3 + Vite + Element Plus + Pinia + Vue Router + ECharts + Axios组件化 SPA，全部依赖 npm 本地打包，无 CDN 依赖
后端Spring Boot 3.3 + Spring Data JPA + Spring Security + JJWT + LombokRESTful API，JWT 无状态认证，JDK 21
数据库MySQL 8.4（InnoDB，utf8mb4）事务与行锁支持完整，mysql-connector-j 驱动
联调Vite Dev Server 代理 /api、/uploads → Spring Boot(8000)开发环境免跨域配置

2.2 Spring Boot

Spring Boot 是 Java 生态主流的 Web 开发框架，通过自动装配与内嵌容器大幅简化了单体应用的搭建与部署。本系统后端全部基于 Spring Boot 构建：Spring Web 提供 RESTful 接口层；Spring Data JPA 屏蔽 SQL 细节，同时通过 @Lock 注解保留了对悲观锁的底层控制能力；Bean Validation 在接口入口完成入参校验；Lombok 消除实体类的样板代码。工程按业务域划分为 controller / service / repository / entity / dto 五层，职责边界清晰。

2.3 Vue 3 与 Element Plus

Vue 3 的组合式 API（Composition API）配合 <script setup> 语法，使页面逻辑以函数为单位组织，比选项式 API 更适合中大型项目。Element Plus 提供表格、表单、抽屉、标签页等成品组件，保证界面风格统一；ECharts 用于管理端统计看板的折线图、饼图与柱状图渲染。前端状态管理采用 Pinia，仅登录态（token + 用户信息）进入全局 store，页面私有数据留在组件内，职责清晰。

2.4 JWT 认证机制

系统采用 JJWT 实现基于 Token 的无状态认证：登录成功后服务端签发 access token（有效期 120 分钟）与 refresh token（有效期 7 天）；前端将 token 存入 localStorage，axios 请求拦截器自动附加 Authorization: Bearer 头，响应拦截器统一处理 401 跳转登录。后端通过 Spring Security 过滤器解析 JWT 并装载用户上下文，按"公开 → 登录可读 → 管理员可写 → 仅本人资源"四级控制访问。无状态认证使后端可以水平扩展，不依赖服务端会话存储。

2.5 MySQL 数据库

MySQL 的 InnoDB 存储引擎支持事务（ACID）与行级锁，这是本系统审核并发控制正确性的基础。选择 utf8mb4 字符集以完整支持中文与表情符号。表结构由 JPA 实体自动建表（ddl-auto: update），连接驱动使用官方 mysql-connector-j。

3 需求分析

3.1 可行性分析

技术可行性：Spring Boot 与 Vue 3 均为成熟的主流框架，社区资料丰富；MySQL、JWT 技术栈稳定；开发机配置即可承载开发与演示运行。

经济可行性：系统全部基于开源软件构建，零授权成本；硬件仅需一台普通 PC 即可部署运行。

操作可行性：用户端操作路径为"浏览宠物 → 查看详情 → 填写申请 → 提交"，全程不超过四步；管理端为常规表格操作，无需培训即可上手。

3.2 功能需求

系统分用户端与管理端两个角色。

用户端功能：

  1. 注册（用户名 + 密码，BCrypt 加密存储）、登录、退出；
  2. 浏览待领养宠物列表，支持物种筛选（狗/猫/其他）、名字/品种关键词搜索与分页；
  3. 查看宠物详情（物种、品种、性别、月龄、毛色、健康状况、所在救助站、介绍）；
  4. 对"待领养"宠物提交领养申请（必填申请理由与居住条件，可标注养宠经验）；
  5. 查看我的申请列表，待审核状态可取消，已通过的申请展示回访安排与回访结果；
  6. 浏览救助站列表，查看各站容量占用情况；
  7. 个人中心维护手机号、邮箱，校验原密码后修改密码。

管理端功能：

  1. 数据统计看板（宠物总数/待领养/待审核/待回访指标卡 + 近 6 个月申请与回访趋势、物种分布、申请状态分布图表）；
  2. 宠物信息管理（增删改查、上架/下架、分配救助站，入站校验容量）；
  3. 救助站管理（增删改查，容量不小于当前在养数，有在养宠物时禁止删除）；
  4. 领养审核（通过/驳回，驳回必填审核意见，通过后宠物自动置为已领养并驳回同宠物其余待审申请）；
  5. 回访管理（为已通过的领养登记回访计划，电话/上门两种方式，完成时必填回访记录）；
  6. 用户管理（列表、角色调整、启用/禁用，不能操作自己的账号）；
  7. 仅限管理员访问，普通用户访问自动拦截。

3.3 业务流程

领养主流程为：用户浏览宠物并提交申请 → 系统校验（宠物为待领养状态 + 同人同宠物无待审申请）→ 生成待审核单 → 管理员通过/驳回 → 通过后宠物置为"已领养"，同一宠物其余待审申请自动驳回并附审核意见 → 管理员为已通过的领养登记回访计划 → 回访完成填写回访记录 → 用户端可实时查看审核状态、审核意见与回访安排。任一环节取消或驳回均完整留痕。

3.4 非功能需求

  • 并发安全：同一宠物在任意并发压力下只允许一单审核通过；
  • 数据隔离：用户只能查看与操作本人申请，越权操作返回 403；
  • 业务约束：救助站在养宠物数不得超过容量上限，缩容不得小于当前在养数；
  • 性能：列表接口分页返回，pageSize 上限 100，禁止全量返回；
  • 可维护：前后端分离、按业务域分模块（accounts / pets / shelters / adoptions / followups）。

4 系统概要设计

4.1 系统架构

系统采用典型的前后端分离三层架构：

浏览器（Vue 3 SPA）
   │  HTTP / JSON，JWT 认证
   ▼
Spring Boot（Controller → Service → Repository，Spring Data JPA）
   │  mysql-connector-j
   ▼
MySQL 8.4（InnoDB）

4.2 功能结构

系统功能结构如图 4-1 所示（用户端）与图 4-2 所示（管理端）。

在这里插入图片描述

图 4-1 用户端宠物列表界面

在这里插入图片描述

图 4-2 管理端宠物管理界面

4.3 数据库设计

系统核心业务表为五张：users（用户）、shelters（救助站）、pets（宠物）、adoption_applications（领养申请）、follow_ups（领养回访）。用户表以 role 字段区分普通用户（0）与管理员（1），密码 BCrypt 哈希存储；宠物表通过 shelter_id 外键归属救助站；领养申请表通过 user_id、pet_id 外键关联，状态机为：待审核 0 → 已通过 1 / 已驳回 2 / 已取消 3，其中 1、2 为终态；回访表通过 adoption_id 外键关联申请，状态机为：待回访 0 → 已完成 1 / 已取消 2，完成时回访记录必填。

详细的表结构、外键关系与状态机说明，见 docs/数据库设计.md。

4.4 审核并发控制设计（核心）

领养审核的关键风险是：两个管理员同时通过同一宠物的两笔待审申请，或管理员审核与申请人重复提交并发发生。若采用"先查状态、再更新"的两步操作，两步之间存在竞态窗口，宠物可能被重复领养。本系统将状态校验与状态流转收敛到同一事务，并对宠物行加悲观写锁：

// PetRepository
@Lock(LockModeType.PESSIMISTIC_WRITE)
Optional<Pet> findByIdForUpdate(@Param("id") Long id);

// AdoptionService.approve：事务内先锁宠物行，再校验并流转状态
Pet pet = petRepository.findByIdForUpdate(application.getPet().getId())
        .orElseThrow(() -> ApiException.notFound("宠物不存在"));
if (pet.getStatus() != 0) {
    throw ApiException.conflict("该宠物已被领养或下架");
}
pet.setStatus(1);  // 宠物置为已领养，申请置为已通过

第二个并发事务在锁释放后才会读到宠物行，此时 status != 0 必然成立，返回 409——行锁保证了"校验-流转"之间无窗口。审核通过后，同一宠物的其余待审申请在同一事务内自动驳回，从源头消除多申请并发的悬挂数据。

与审核并发同级的另一约束是救助站容量：宠物入站、换站与救助站缩容时统一校验在养数量，超过容量返回 400：

if (petRepository.countByShelterIdAndStatus(shelterId, 0) >= shelter.getCapacity()) {
    throw ApiException.badRequest("该救助站容量已满");
}

5 系统详细设计与实现

5.1 认证模块

系统登录页如图 5-1 所示。用户使用用户名 + 密码登录，登录成功后按角色跳转对应首页；注册仅需用户名与密码，密码经 BCrypt 哈希后入库，接口不返回敏感字段。

在这里插入图片描述

图 5-1 系统登录界面

5.2 宠物浏览与领养申请模块（用户端）

用户登录后进入宠物列表页（图 5-2）。页面顶部为领养宣传横幅，下方提供物种筛选（全部/狗狗/猫咪/其他）、名字与品种关键词搜索，宠物以卡片形式展示照片、名称、品种、月龄与所在救助站，底部分页浏览。

在这里插入图片描述

图 5-2 宠物列表界面

点击卡片进入宠物详情页（图 5-3）。页面展示宠物的完整档案，包括物种、品种、性别、月龄、毛色、健康状况、入库日期与所在救助站；底部"申请领养"按钮在宠物非"待领养"状态时自动禁用。

在这里插入图片描述

图 5-3 宠物详情界面

申请弹窗要求填写申请理由与居住条件（均必填），可标注是否有养宠经验。提交时服务端依次校验：宠物是否存在、是否为待领养状态（否则 409）、同人同宠物是否已有待审申请（否则 409），校验通过后生成待审核申请单。

5.3 我的申请模块（用户端）

"我的申请"列表展示本人全部申请记录（图 5-4），每条含宠物信息、申请理由、居住条件、养宠经验、提交时间与状态标签；待审核状态可申请取消，已驳回记录展示审核意见，已通过记录下方展示回访安排（回访方式、日期、状态与回访结果）。

在这里插入图片描述

图 5-4 我的申请界面

5.4 救助站浏览模块（用户端）

救助站列表页（图 5-5）展示各救助站的名称、地址、联系电话、负责人与简介，并显示容量占用进度条；支持按名称、地址关键词搜索，用户可由此了解宠物所在的救助站情况。

在这里插入图片描述

图 5-5 救助站列表界面

5.5 个人中心模块（用户端）

个人中心（图 5-6）支持维护手机号、邮箱等基本资料，修改密码需校验原密码后设置新密码，表单均带前端必填与格式校验。

在这里插入图片描述

图 5-6 个人中心界面

5.6 宠物管理模块（管理端）

管理员在后台维护宠物信息（图 5-7），包括名称、物种、品种、性别、月龄、毛色、健康状况、照片与介绍；支持状态筛选与关键词搜索，可执行新增、编辑、上架/下架与删除。编辑时选择所在救助站，若该站在养数量已达容量上限，服务端返回 400 拒绝保存。

在这里插入图片描述

图 5-7 宠物管理界面

5.7 领养审核模块（管理端）

审核列表按状态筛选展示全部申请（图 5-8），每条含申请人、宠物、申请理由、居住条件与养宠经验；点击可查看完整详情抽屉。通过即时生效：宠物自动置为"已领养"，同一宠物其余待审申请自动驳回并填写审核意见；驳回必填审核意见，申请人端实时可见。

在这里插入图片描述

图 5-8 领养审核界面

5.8 回访管理模块（管理端）

回访管理页（图 5-9）为已通过的领养登记回访计划，选择回访日期与方式（电话回访/上门回访）；回访完成后必须填写回访情况记录方可提交，也可取消回访。回访状态与结果同步展示在用户端"我的申请"中，形成领养后的跟踪闭环。

在这里插入图片描述

图 5-9 回访管理界面

5.9 救助站管理模块（管理端）

救助站管理页（图 5-10）以进度条直观展示各站在养数量与容量；新增与编辑时容量不得小于当前在养数，有在养宠物的站点禁止删除，保证数据的业务完整性。

在这里插入图片描述

图 5-10 救助站管理界面

5.10 数据统计模块（管理端）

统计看板（图 5-11）提供宠物总数、待领养、待审核申请、待回访四张指标卡，以及近 6 个月领养申请趋势（折线）、宠物物种分布（饼图）、申请状态分布（柱状）与近 6 个月回访趋势（折线）四张图表，为救助站运营提供量化依据。

在这里插入图片描述

图 5-11 数据统计界面

5.11 用户管理模块（管理端）

用户管理页（图 5-12）支持按用户名、手机号搜索，可调整用户角色（普通用户/管理员）与启用/禁用账号；为保护系统可用性，管理员不能对本人账号执行禁用或降权操作。

在这里插入图片描述

图 5-12 用户管理界面

6 系统测试

6.1 测试目的与方法

系统测试的目的是验证各功能模块的正确性、权限隔离的有效性与并发控制的可靠性。测试采用两种方法：

  1. 服务层单元测试：使用 JUnit 5 + Mockito 对领养审核与救助站两个核心服务共 15 个场景做自动化断言（仓储层全部 Mock，不依赖数据库），随 mvn test 一键执行；
  2. 功能测试：按角色（用户/管理员）在浏览器中走查全部业务流程。

6.2 测试环境

项目配置
操作系统Windows 11
后端JDK 21 + Spring Boot 3.3.13 + Spring Data JPA + JJWT
数据库MySQL 8.4（InnoDB，utf8mb4）
前端Node.js 22 + Vue 3 + Element Plus
浏览器Chrome 最新版

6.3 核心测试用例

编号测试场景预期结果实测
T01审核通过一笔待审申请申请置为已通过，宠物置为已领养通过
T02重复审核已处理的申请400「该申请已处理，请勿重复操作」通过
T03审核通过时宠物已被领养/下架409「该宠物已被领养或下架」通过
T04审核驳回状态置为已驳回，审核意见落库通过
T05同人同宠物重复提交申请409「您已提交过该宠物的领养申请」通过
T06对已下架宠物提交申请409通过
T07取消他人申请403「只能取消自己的申请」通过
T08取消已驳回/已通过申请400「仅待审核的申请可取消」通过
T09取消待审核申请状态置为已取消通过
T10宠物入站时救助站容量已满400「该救助站容量已满」通过
T11容量未满时宠物入站正常返回救助站通过
T12删除有在养宠物的救助站400 拒绝删除通过
T13删除空救助站删除成功通过
T14救助站缩容至小于当前在养数400 拒绝修改通过
T15正常更新救助站信息更新成功通过

其中 T01-T03 验证审核状态机与并发防护的状态前置校验，T05-T06 验证申请创建的去重与状态约束，T07-T08 验证数据隔离（仅本人资源可操作），T10-T15 验证救助站容量与完整性约束。

6.4 并发安全验证

在 MySQL 8.4 下对审核路径做并发验证：针对同一宠物的两笔待审申请，两个审核请求同时提交通过操作，悲观行锁使二者串行执行，实测仅一单审核成功、另一单返回 409，无重复领养；审核通过的事务同时将该宠物其余待审申请置为已驳回，无悬挂数据。这印证了 4.4 节的设计：应用层状态校验的正确性以数据库行锁为前提。

6.5 测试结果

后端 15 个服务层单元测试全部通过（mvn test，Mockito Mock 仓储层，无需测试库）；前端全部页面按角色走查正常，权限拦截（未登录跳转、非管理员拦截）符合预期。系统满足设计目标。

结 论

本文完成了基于 Spring Boot + Vue 3 的宠物领养管理系统的全流程开发。系统在功能层面覆盖了"宠物浏览 → 领养申请 → 审核 → 回访跟踪"完整业务闭环，并以救助站容量约束形成真实业务规则；在技术层面给出了两个超出常规 CRUD 选题的设计：一是以"事务 + 悲观行锁"解决领养审核的并发安全问题，二是以回访记录表与容量约束将业务流程延伸到领养后跟踪与站点资源管理。15 个单元测试与并发实测验证了设计的正确性。

需要源码的私信联系获取！！

avatar
文章
阅读
粉丝