平时做的管理系统不少，但真正让我觉得"技术有意义"的，还是这个以流浪动物救助为主题的网站项目。前后端分离、基于SpringBoot+Vue+MyBatis+MySQL构建，既是一套标准的企业级开发范本，也把真实的业务场景落了地。流浪动物救助机构最缺数字化的信息管理工具，这套系统刚好补上了这个缺口——动物档案、领养申请、救助登记、公告发布全部在线化，普通浏览用户不用登录也能看动物信息，管理员在后台维护数据，整个流程走得很顺。

这个项目适合正在学前后端分离开发的人拿来当练手范例，适合准备毕业设计或求职项目的开发者做二次开发基础，也适合真正有救助组织背景的人直接部署使用。技术栈不花哨，但都是市场主流，麻雀虽小五脏俱全。这篇文章我会从设计思路、数据库结构、前后端核心实现、部署步骤到排坑心得，一条线讲清楚，照着走就能跑起来。

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

1.1 核心功能拆解

动手做这个系统之前，我先把"流浪动物救助"这个场景的业务流程捋了一遍。救助组织日常最烦的事儿不是缺粮，而是信息太分散——今天有人在某地捡到一只猫，发了条朋友圈；明天有人想领养，却不知道去哪找靠谱的动物来源。中间全靠人工对接，效率低到离谱。

所以我给这个系统划了这几个核心模块：

• 动物信息管理：管理员可以录入、修改、上下架流浪动物的档案，包含品种、年龄、性别、健康状况、照片、救助时间等字段，这是整个系统的信息底座。
• 领养申请流程：普通用户看上某只动物后，可以提交领养申请，填写居住情况、养宠经验等信息；管理员在后台审核，状态从"待审核"流转到"已通过"或"已拒绝"。
• 救助登记：用户遇到流浪动物时可以提交救助信息，填上发现地点、动物状态、联系方式，管理员收到后安排后续处理。
• 用户系统：区分普通用户和管理员两种角色，用JWT做登录认证，权限不同看到的页面不同。
• 公告资讯：救助组织发布领养活动、物资募集、文明养宠科普等公告，让平台不只是一个"数据库"，还有内容属性。

这套模块划分的逻辑是：让普通用户做得少、看得多，让管理员管得多、操作快。前端页面风格偏温暖明快，毕竟救助类产品跟电商后台不一样，用户路径需要一点情感引导。

1.2 为什么选这套技术栈

选型这件事，我个人有个原则：面向场景选技术，不面向新技术选技术。很多人喜欢一上来就上微服务、K8s，结果项目复杂度比业务复杂度还高，得不偿失。

这个项目的定位是单体应用，但要求前后端能分离开发、并行推进，所以选了SpringBoot+Vue这套经典组合：

• SpringBoot：省去了繁重的XML配置，内嵌Tomcat，一条命令就能启动后端服务。生态成熟，做接口开发效率极高，尤其适合这类以CRUD+业务状态流转为主的管理系统。
• Vue：渐进式框架，对团队里刚接触前端的人非常友好。组件化开发让页面逻辑清晰，配合Element UI这类组件库能很快搭出管理后台。
• MyBatis：SQL由开发者自己掌控，比起全自动ORM（比如JPA），更适合这种存在多表联查、自定义统计查询的场景。后面排查SQL性能问题也方便，直接把日志打开就能看到实际执行的语句。
• MySQL：免费的社区版足够满足这个量级的数据存储需求，InnoDB引擎支持事务，保证领养申请状态流转这类多步操作的数据一致性。

有人可能会问，为什么不用Redis做缓存？我的回答是：不是所有项目都需要缓存。动物信息表数据量最多也就几千条，MySQL扛起来毫无压力，引入Redis反而增加部署复杂度。技术是个工具箱，要用对地方。

2. 数据库设计与表结构拆解

2.1 核心表设计与字段说明

数据库设计是整个系统最见功底的部分，表设计得好，后面写接口就顺；表设计拉胯，写业务的时候全在跟数据和字段打架。我在设计时遵循了两条主原则：单表职责单一，多表冗余可控。

核心表一共六张：

这里提一个我踩过坑的细节：不要把管理员单独建一张表。早期版本我确实单独建了admin表，后来发现绝大多数业务逻辑（比如"查询登录用户的信息"）都要先判断是普通用户还是管理员，两张表联查会让接口变复杂。用role字段区分就行了，这是典型的"需求驱动设计"。

2.2 状态字段的设计哲学

几乎所有业务表里都有status字段，但它们的取值含义是完全独立的，千万别设计成一套通用的枚举：

• animal.status：0-待审核，1-展示中，2-已领养，3-已下架
• adoption.status：0-待审核，1-已通过，2-已拒绝，3-已取消
• rescue.status：0-待处理，1-处理中，2-已完成

这样设计的好处是，每个业务域的状态流转在自己内部闭环，写业务代码时逻辑非常清楚。比如领养申请的流转核心保障是：申请通过后，必须同步把对应动物的status从"展示中"改成"已领养"，这两个操作要放在一个事务里，否则就会出现"动物明明已被领养，却还在列表里展示"的数据不一致问题。

数据库字符集这块也提醒一句：统一用utf8mb4，不是utf8。utf8mb4是真正的四字节UTF-8编码，能存emoji和一些特殊字符，流浪动物救助这个场景里，用户描述动物的时候经常用表情，不用utf8mb4存进去就是乱码。

3. 后端SpringBoot+MyBatis核心实现

3.1 项目分层与接口设计

后端代码我严格按三层架构组织：Controller（接口层，只做参数接收和返回值包装）→ Service（业务层，写核心逻辑）→ Mapper（数据层，对应SQL操作）。很多新手喜欢把业务逻辑写在Controller里，几十行代码堆在一起，当时觉得爽，后面改需求时快烦死了。

接口设计遵循RESTful风格，几个关键的接口路径：

POST /api/auth/login 登录 GET /api/animal/list 动物分页列表（支持关键词搜索/类型筛选） GET /api/animal/detail/{id} 动物详情 POST /api/adoption 提交领养申请 GET /api/adoption/my 我提交的领养申请 POST /api/animal 管理员新增动物 PUT /api/animal/{id} 管理员编辑动物 DELETE /api/animal/{id} 管理员删除动物 GET /api/rescue/list 救助信息列表（管理员） POST /api/rescue 用户提交救助登记

统一返回结构是我每次做项目都会先定好的基础设施，所有接口返回Result<T>对象，包含code、message、data三个字段。前端拿到结果后不用做一堆判空处理，直接看code是不是200就行，省事。

3.2 登录认证与权限控制

这个系统我用了JWT做登录认证，流程是：登录成功后，后端生成一个包含用户ID和角色的Token返回给前端，前端存在localStorage里，之后每次请求都在请求头带上Authorization: Bearer <token>。

后端用一个**拦截器（Interceptor）**统一处理Token校验，我习惯写一个AuthInterceptor，在preHandle方法里解析Token并验证有效性，然后把当前用户信息放到ThreadLocal里，这样Service层任何时候想拿当前用户ID都能拿到，不用在每个接口里重复传参。

权限控制这块，我加了一个很实用的设计：用**自定义注解@RequireRole**标记需要管理员权限的接口，配合拦截器实现角色校验。代码结构大概是：

@Target(ElementType.METHOD) @Retention(RetentionPolicy.RUNTIME) public @interface RequireRole { String value() default "admin"; }

在需要管理员权限的Controller方法上加上@RequireRole("admin")，拦截器扫描到这个注解就校验角色，不满足直接返回403。这种方式比在Service代码里写if(!role.equals("admin"))要优雅得多，也更好维护。

3.3 关键业务逻辑：领养申请与状态流转

领养申请是整个系统业务复杂度最高的模块，我在Service层写了完整的流程控制。核心代码如下：

@Transactional public void approveAdoption(Integer adoptionId) { AdoptionRequest request = adoptionMapper.selectById(adoptionId); if (request == null) { throw new BusinessException("领养申请不存在"); } // 1. 更新申请状态 request.setStatus(2); // 已通过 adoptionMapper.updateById(request); // 2. 将对应动物状态改为已领养 Animal animal = animalMapper.selectById(request.getAnimalId()); if (animal != null) { animal.setStatus(2); // 已领养 animalMapper.updateById(animal); } // 3. 将其他待审核的申请自动标记为已取消 List<AdoptionRequest> pendingList = adoptionMapper.selectByAnimalIdAndStatus(request.getAnimalId(), 0); if (pendingList != null && !pendingList.isEmpty()) { for (AdoptionRequest pending : pendingList) { if (!pending.getId().equals(adoptionId)) { pending.setStatus(3); // 已取消 adoptionMapper.updateById(pending); } } } }

这里有三层业务考量：

1. 事务保证：@Transactional确保申请通过、动物状态更新、其他申请作废这三步操作要么全部成功，要么全部回滚。如果少了第三步，就会出现"同一只动物同时被多个申请绑定"的怪象。
2. 状态冲突处理：一只动物被人领养后，其他排队申请就不能继续处于"待审核"状态，必须自动取消。
3. 拒绝时的恢复逻辑：如果管理员拒绝了申请，要把动物的状态从"待审核"恢复回去——因为动物还没被领养，不能一直挂着。

这些状态流转规则如果不提前想清楚，测试阶段一定会冒出各种"幽灵数据"问题。

3.4 MyBatis多表联查与XML编写

MyBatis的SQL写在Mapper XML文件里，我喜欢这种"SQL掌控权在开发者手里"的感觉。项目里用到的核心SQL场景主要是两个：

第一个是动物列表分页查询，支持按种类（猫/狗）筛选和关键词搜索：

<select id="selectPage" resultType="com.example.pojo.Animal"> SELECT * FROM animal <where> <if test="species != null and species != ''"> AND species = #{species} </if> <if test="keyword != null and keyword != ''"> AND (name LIKE CONCAT('%', #{keyword}, '%') OR breed LIKE CONCAT('%', #{keyword}, '%')) </if> </where> ORDER BY create_time DESC </select>

注意一下<where>标签的妙用：如果所有条件都是空，它不会生成WHERE关键字；如果有条件满足，它自动处理掉第一个AND，避免写成WHERE AND species = ...这种SQL语法错误。这是MyBatis动态SQL的基础操作，但很多人初学时会疏忽。

第二个是领养申请带动物信息的联查，管理员的审核列表需要同时显示申请人信息和动物信息：

<select id="selectWithAnimal" resultType="com.example.pojo.vo.AdoptionVO"> SELECT a.*, u.nickname AS user_nickname, u.phone AS user_phone, an.name AS animal_name, an.species AS animal_species, an.breed AS animal_breed FROM adoption a LEFT JOIN user u ON a.user_id = u.id LEFT JOIN animal an ON a.animal_id = an.id ORDER BY a.apply_time DESC </select>

LEFT JOIN而不是INNER JOIN的理由：管理员要看的是所有申请记录，即使某些数据（比如用户已注销）缺失，申请记录本身仍应该展示。这个细节在高并发的联查场景下尤为重要。

4. 前端Vue页面实现与交互

4.1 前端项目结构与路由设计

前端我用Vue 2 + Vue Router + Vuex + Element UI + Axios这一套标准配置。Vue 3虽然已经出来很久了，但我个人觉得如果是学习或者快速交付，Vue 2的生态组件最稳，排查问题也容易搜到答案。

项目目录结构：

src/ ├── api/ // 接口请求统一封装 │ ├── animal.js │ ├── adoption.js │ └── user.js ├── assets/ // 静态资源（图片、样式） ├── components/ // 通用组件 ├── router/ // 路由配置 ├── store/ // Vuex状态管理 ├── views/ │ ├── home/ // 前台页面 │ │ ├── Home.vue │ │ ├── AnimalList.vue │ │ ├── AnimalDetail.vue │ │ ├── AdoptionForm.vue │ │ └── RescueForm.vue │ └── admin/ // 后台管理页面 │ ├── Dashboard.vue │ ├── AnimalManage.vue │ ├── AdoptionAudit.vue │ └── RescueManage.vue └── main.js

路由设计上做了游客/普通用户/管理员三级的访问控制，用Vue Router的beforeEach守卫实现：

router.beforeEach((to, from, next) => { const token = localStorage.getItem('token'); const role = localStorage.getItem('role'); if (to.meta.requiresAdmin && role !== 'admin') { next('/login'); } else if (to.meta.requiresAuth && !token) { next('/login'); } else { next(); } });

requiresAuth和requiresAdmin是路由配置里的meta字段，在定义路由时声明好。前端权限控制只能保证"界面不显示、路由不能跳"，真正的数据安全必须靠后端接口校验兜底——前端权限是体验优化，后端权限才是安全底线。

4.2 核心页面与组件实现细节

动物卡片列表页是这个系统的门面，我设计了一个瀑布流卡片布局，每张卡片展示动物封面、名字、品种和领养状态。核心数据绑定逻辑：

<template> <div class="animal-card" @click="goDetail(item.id)"> <el-image :src="item.coverImage" fit="cover" lazy /> <div class="info"> <h3>{{ item.name }}</h3> <p>{{ item.species }} · {{ item.breed }}</p> <el-tag :type="statusMap[item.status].type"> {{ statusMap[item.status].text }} </el-tag> </div> </div> </template> <script> export default { data() { return { statusMap: { 0: { text: '待审核', type: 'warning' }, 1: { text: '待领养', type: 'success' }, 2: { text: '已领养', type: 'info' }, 3: { text: '已下架', type: 'danger' } } } } } </script>

这里有个实用性极强的细节：列表页的数据变化状态映射要常驻在前端。后端返回的status永远只是一个数字，如果前端每次使用都要判断一遍，代码会又臭又长。把状态和文案、颜色统一映射管理，是管理后台页面开发的通用实践。

图片上传组件用的是Element UI的el-upload配合后端接口实现文件存储。后端保存图片的方式有很多种，这个项目我用了最简单可靠的方案：本地上传目录 + 静态资源映射。服务器上建一个/upload目录存放图片文件，数据库只存访问路径。不用OSS、不用云存储，原因还是那条：够用就行。

上传接口的核心配置：

@Value("${file.upload-path}") private String uploadPath; @PostMapping("/upload") public Result<String> upload(@RequestParam("file") MultipartFile file) { // 生成唯一文件名，防止重名覆盖 String originalFilename = file.getOriginalFilename(); String ext = originalFilename.substring(originalFilename.lastIndexOf(".")); String filename = System.currentTimeMillis() + "_" + UUID.randomUUID().toString().substring(0, 8) + ext; File dest = new File(uploadPath + "/" + filename); file.transferTo(dest); return Result.success("/upload/" + filename); }

文件重名问题是每个做上传功能的人都会遇到的坑，所以文件名里混入了时间戳和随机串，目的就是让重名概率近乎为零。

4.3 后台管理页面：表格+弹窗+表单

后台管理页面的套路基本一致：一条表格展示列表数据，一个弹窗承载新增/编辑表单，一个删除确认框防止误操作。我以动物管理页为例说一下核心思路：

页面的关键逻辑：

1. 进入页面时调用fetchList()拉取第一页数据；
2. 分页组件变化时触发handlePageChange，重新拉对应页的数据；
3. 点击"新增/编辑"时弹窗，表单校验通过后调用新增或更新接口；
4. 操作成功后必须刷新列表，让用户看到最新状态。

这里有一个提升用户体验的小技巧：新增和编辑共用同一个表单组件，通过判断dialogType来区分是调createAnimal还是updateAnimal接口。减少了代码重复，也方便表单校验逻辑的统一。

5. 完整部署教程（本地运行与服务器上线）

5.1 本地环境准备

我默认你能跟着这套环境跑起来：JDK 1.8+、Maven 3.6+、Node.js 12+、MySQL 5.7+、Navicat或任意数据库管理工具。版本不用完全一致，但别差太多，尤其是Node与Vue 2的兼容性。

如果你是本机第一次跑这种项目，建议把Maven镜像设置为国内仓库源，否则第一次下载SpringBoot依赖会等到怀疑人生。Maven安装目录下的conf/settings.xml里修改镜像地址，这个细节能省半小时等待时间。

5.2 数据库初始化与后端启动

第一步，用Navicat创建一个新数据库，名字随意，比如animal_rescue，字符集选utf8mb4，排序规则选utf8mb4_general_ci。

第二部，将项目根目录下提供的animal_rescue.sql脚本文件执行一遍，它会把建库建表语句和演示数据全部导入。SQL文件里我包含了十几个动物样品数据和几个测试用户账号，方便你立即看到效果。

第三步，修改后端的配置文件application.yml里的数据库连接：

server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/animal_rescue?useUnicode=true&characterEncoding=utf8mb4&serverTimezone=Asia/Shanghai username: root password: 你的数据库密码 driver-class-name: com.mysql.cj.jdbc.Driver mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.example.pojo

两个容易踩的坑：

• serverTimezone=Asia/Shanghai必须加，否则MySQL 8.x默认时区跟本地时间差8小时，数据创建时间全是错的。
• characterEncoding=utf8mb4要跟数据库的字符集一致，防止中文乱码。

第四步，在IDEA里打开后端项目，等待Maven下载完依赖，直接运行主启动类。看到"Started Application in xxx seconds"就表示后端启动成功了。

5.3 前端启动与联调

前端项目打开终端，执行两条命令：

npm install npm run serve

npm install需要等一会儿，同样建议把npm源切到国内镜像，否则下载Internet速度会让你怀疑人生。启动成功后，终端会显示访问地址，一般是http://localhost:8081。

这里要注意：后端8080端口，前端8081端口，两者不同。那前端怎么访问后端接口？通过代理转发。

在Vue项目的vue.config.js里配置开发环境代理：

module.exports = { devServer: { port: 8081, proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } } };

这样前端页面里请求/api/animal/list时，开发服务器会自动把请求转发到后端的8080端口，避免了前后端联调时最典型的跨域问题。注意生产环境部署时，这个代理就不工作了，需要靠Nginx来做反向代理。

5.4 服务器部署上线

本地跑通后，发布到线上服务器是另一个常见需求。我把步骤整理清楚：

后端打包部署：

mvn clean package -DskipTests

这条命令会生成一个target/animal-rescue-0.0.1-SNAPSHOT.jar。把jar包上传到服务器的指定目录（比如/webapps），然后启动：

nohup java -jar -Dfile.encoding=utf-8 animal-rescue-0.0.1-SNAPSHOT.jar > /webapps/log.log 2>&1 &

nohup让进程在SSH断开后继续运行，日志输出到log文件方便排查。如果你用systemd管理服务，写一个服务单元文件会更专业。

前端构建与Nginx配置：

npm run build

构建产物在dist/目录，把dist里的文件上传到服务器Nginx的web目录（如/webapps/dist）。

Nginx配置核心：

server { listen 80; server_name 你的域名或IP; # 前端页面 location / { root /webapps/dist; index index.html; try_files $uri $uri/ /index.html; # 历史模式路由回退 } # 后端接口反向代理 location /api/ { proxy_pass http://localhost:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } # 图片访问 location /upload/ { alias /webapps/upload/; } }

这里有个关键配置：try_files $uri $uri/ /index.html;。因为Vue Router如果用了history模式，前端路由（比如/animal/detail/1）在刷新页面时，Nginx会去磁盘找这个路径对应的文件，找不到就会报404。加上这行配置后，所有找不到的路径都会回退到index.html，由前端路由接管。

改完Nginx配置执行nginx -s reload，整个系统就能通过域名访问了。

6. 常见问题与排查技巧实录

6.1 高频问题速查表

把我被问得最多的问题整理成一个表格，方便你留着备查：

6.2 我踩过最深的坑

这里专门分享几个我在做这个项目时耗费最久才解决的实际问题：

第一个坑：文件上传后保存的路径与访问路径不匹配

我在本地开发时，上传目录用的是C:/upload/，数据库存的是/upload/xxx.jpg，浏览器访问也正常。发布到Linux服务器后，上传的文件存在了/upload/xxx.jpg，但Nginx配置的alias写成了/webapps/upload/，导致图片访问404。排查了半天才想起来，Nginx的alias路径必须和实际文件系统路径完全一致。

第二个坑：前后端联调时，中文参数在GET请求中乱码

这个比较隐蔽。POST请求有JSON格式，一般不会乱码，但GET请求带中文关键词搜索时，Tomcat默认的URI编码不是UTF-8。解决办法是在application.yml里把Tomcat的URI编码设置为UTF-8：

server: tomcat: uri-encoding: UTF-8

第三个坑：领养申请审核状态与动物状态不同步

这是业务逻辑层面的坑，测试时用两个管理员账号同时审核同一只动物的不同申请，结果数据乱了。原因是最早版本没加事务控制，后来补上了@Transactional并在Service层增加了状态冲突检测逻辑，问题才解决。这也印证了前面说的：多步操作必须事务控制，这是系统的可靠性底线。

6.3 几个提升效率的实操心得

• 接口测试优先用Postman/Apifox，不要一上来就在前端页面里调。先把每个接口的边界情况测完（登录失效、参数为空、传非法ID），再去做前端联调，能省一大半联调时间。
• 后端日志打关键节点，特别是这一句"接收参数、校验结果、操作结果"。排查问题时，日志是你唯一的线索来源，哪怕只加一句log.info("审核通过: adoptionId={}, animalId={}", id, animalId);都能让排查速度翻倍。
• 用Git从小项目第一天就建立版本管理。我开始做这个系统时就直接初始化了Git仓库，每次改版本都提交一次。有一次改前端样式把整个页面的布局改崩了，来回撤销太麻烦，直接回滚到上一个稳定提交点，省了半小时。

结尾：再分享一点真实感受

做完这个项目，我最深的体会不是技术环节的哪个技巧很巧妙，而是一个系统能否真正解决问题，取决于你多懂业务。流浪动物救助这个场景，最核心的不是技术实现，而是信息流转的闭环——发现人提交信息、组织方审核跟进、领养人申请、最终完成领养，这条链路上每一步都有真实的人在等待。当你看到动物信息页面上那张等待帮助的照片时，你会意识到自己写的每一行代码背后，都对应着一个具体的生命能否获得关注和机会。

这也是我会推荐所有学习全栈开发的人尝试一次非典型业务场景（不局限于商品交易、图书馆管理这类常见练手项目）的原因。另选一个你身边真实存在的小众需求，把它数字化，你会在开发过程中遇到很多标准教程里不会出现的业务变体，那些"不知道怎么做才对"的时刻，恰恰是最快的成长时刻。

最后，这个项目里所有代码都是开源的，前端构建脚本、后端Jar包、数据库初始化脚本、部署文档都打包在项目目录里了。如果你在学习过程中遇到任何跑不起来的问题，最有效的方法是先看日志——前端看浏览器控制台，后端看Tomcat输出，绝大多数问题日志里都会直接告诉你原因。祝你能顺利跑起来，也希望能在这个世界上，因为你的代码，多一点温暖被看见。