Springboot流浪猫庄园管理系统：从数据库设计到部署答辩全流程实践

去年帮朋友打理一个流浪猫救助站，发现他们的日常管理比想象中更混乱：猫咪档案散落在纸质本子上，哪只打了疫苗、哪只还没做绝育全凭记忆；领养人申请、回访记录靠微信一条条找；捐赠账目在Excel里改了又改，月底统计时数据对不上。就是那次经历让我意识到，一套专门适配流浪猫场景的管理系统比通用的进销存软件实用得多。后来我用Springboot从零做了这个"嗅嗅流浪猫庄园管理系统"，走完了设计、编码、调试、部署、写论文的全流程。这篇文章把整个项目的核心思路、技术选型、数据库设计、功能实现、部署踩坑和论文写作经验全部拆开讲，适合正在做Springboot课程设计或毕业设计的同学，也适合想了解一个完整业务系统从0到1是怎么落地的开发者。

1. 流浪猫庄园为什么要一套管理系统：从场景痛点反推功能清单

先说清楚一个根本问题：流浪猫庄园这种场景，信息化管理到底要解决什么？不是说为了用Springboot而用Springboot，而是这个业务场景确实存在手工管理撑不住的地方。

1.1 纸质台账与微信沟通撑不住的三个节点

我观察到的第一个痛点是猫咪档案的"状态不透明"。一只猫被救助进来，有没有做过体内外驱虫、疫苗打了几针、是否绝育、有没有慢性病——这些信息如果只靠工作人员脑子记，一旦换人交接就断档。更尴尬的是，潜在的领养人问"那只橘猫还在吗"，工作人员要先翻本子再回微信，效率极低。

第二个痛点是领养流程缺少"审批留痕"。救助站不是把猫送出去就完事了，需要对领养人的住房条件、养猫经验、家庭情况做评估，领养后还要定期回访。手工模式下，申请信息可能只是一句微信留言，审核与否全凭负责人个人记忆，出问题后找不到依据。

第三个痛点是捐赠收支对不上。流浪猫庄园的日常开销不小：猫粮、猫砂、疫苗、绝育手术、医疗费，每一笔都需要记录。用Excel虽然能记，但多人协作时容易出现重复录入或漏记，月末汇总对账要花大半天。

1.2 功能清单从业务角色反推

搞清楚痛点后，功能设计就顺理成章了。这套系统我划分了三种角色：管理员、注册用户（访客/领养人/捐赠人）、游客（仅浏览）。

对应的功能模块包括：

• 猫咪信息管理：救助档案的增删改查、图片上传、状态流转（待领养/已预约/已领养）
• 领养申请与审核：用户在线提交申请，管理员审核并填写意见，审核结果实时反馈
• 捐赠管理：登记捐赠人信息、金额、款项用途，支持按时间段统计汇总
• 公告发布：领养活动通知、庄园动态、重要提醒
• 用户管理：注册登录、个人信息维护、我的申请记录
• 首页数据看板：猫只总数、领养成功数、待审核申请数、捐赠总额等指标一览

这套功能清单既覆盖了庄园日常管理的核心场景，又不会因为功能过多导致开发周期失控，作为Springboot课程设计或毕业设计的选题范围，尺度是合适的。

1.3 系统定位决定了技术方案不会太复杂但必须完整

明确了功能边界后，"嗅嗅"这套系统的定位就很清晰：一个以业务数据为核心、包含完整前后端交互、具备基本权限控制的Web信息系统。它的规模决定了我选用的技术方案不追求"高并发、分布式"那套，而是把Springboot + MyBatis-Plus + MySQL这条经典链路用扎实。

对做毕设的同学说一句：不要一上来就堆微服务、Redis、消息队列。评阅老师看的是你能否把一个业务场景完整落地，技术栈够用、逻辑清晰、能说清楚为什么这样选就完全够用。

2. Springboot技术选型的逻辑与项目工程结构规划

技术选型这块我不打算罗列一堆"优点"，只讲针对这个项目的实际取舍，以及我在版本匹配上踩过的坑。

2.1 为什么锁定Springboot 2.x + JDK 1.8而不是Springboot 3.x

做这个项目的时间点，Springboot 3.x已经发布了，但我仍然建议选择Springboot 2.x系列（具体用的2.7.x）。原因有几个：

第一，JDK版本兼容性。Springboot 3.x强制要求JDK 17及以上，而很多学校的实验环境和学生笔记本上装的是JDK 1.8。用Springboot 2.7.x搭配JDK 1.8，本地环境配置成本最低，不会出现"代码没问题但环境跑不起来"的尴尬。

第二，第三方依赖的生态成熟度。MyBatis-Plus、PageHelper、Apache POI、Druid这些国内Java Web项目高频使用的组件，对Springboot 2.x的适配非常成熟，遇到问题能搜到大量资料。Springboot 3.x下部分老版本依赖会报各种兼容错误，排查起来费时间。

第三，部署环境的宽容度。学校提供的服务器或虚拟机，操作系统和已装环境往往比较老旧。Springboot 2.x项目的JVM参数和内存占用要求更友好，打出来的jar包在老服务器上更容易一次跑通。

2.2 工程目录按业务模块分包，别学"包名即层级"的死板写法

很多同学习惯把包结构写成controller、service、mapper、entity四大层，然后所有类都往里面塞。中小型项目这样写能跑，但到后期会有点乱。我采用的是"按业务域分包 + 内部按技术角色分层"的混合方式，结构如下：

code复制com.smellycat.manor
├── controller          # 控制层：接收请求、参数校验、返回结果
├── service             # 业务层：核心业务逻辑、事务控制
│   └── impl
├── mapper              # 数据访问层：MyBatis-Plus的Mapper接口
├── entity              # 实体类：对应数据库表结构
├── dto                 # 前后端交互的对象：接收前端传参、返回视图数据
├── config              # 配置类：拦截器、资源映射、全局异常处理
├── utils               # 工具类：统一返回结果、JWT工具等
└── common              # 公共枚举、常量、异常定义

这种结构的好处是：新增一个功能时，先明确它属于哪个业务域，再往对应包中放文件，开发时能够快速定位；同时也没有丢掉三层架构的分层职责。比如用户提交领养申请，接收参数的类是ApplyDTO而不是直接接收实体类，避免前端把敏感字段传进来覆盖库里的数据。

2.3 核心依赖清单与版本选择

我把pom.xml里的核心依赖列出来，版本号是实测过能稳定配合的：

推荐使用Maven进行依赖管理，版本号最好在pom里显式声明，不要全靠父工程传递性依赖，否则版本升级时容易出问题。

3. 数据库设计：猫只档案、领养审核与捐赠记录的表结构拆解

开发一个管理系统的核心其实是数据库设计。表结构合理，后面写代码就顺；表结构有硬伤，代码写了一半再改表，痛苦指数翻倍。

3.1 从"业务流程要查什么"倒推数据表

我在设计表结构时，不先画ER图，而是先列出业务上需要回答的关键问题：

• 列表页要展示哪些字段？——猫咪名字、照片、品种、年龄、性别、绝育状态、领养状态
• 详情页要展示哪些字段？——加上疫苗记录、救助时间、健康状况描述、救助人
• 用户提交领养申请时填什么？——姓名、手机号、住址、住房类型、养猫经验、申请理由
• 管理员审核需要看什么？——申请人的历史申请记录、猫当前状态、已领养数量
• 捐赠统计要按什么维度？——按时间、按用途、按捐赠人

基于这些问题，最终确定了六张核心表：管理员表、用户表、猫咪信息表、领养申请表、捐赠记录表、公告表。

3.2 核心表结构说明

这里重点说三张最有业务代表性的表。

猫咪信息表（cat_info）

这里有个设计心得：cat_age为什么用varchar，不用int？因为流浪猫的年龄很多是医生或救助人估算的，可能是"2岁左右"或"3-4个月"，用字符串存储比非用一个精确数字更符合实际。

领养申请表（adopt_apply）

捐赠记录表（donation_record）

金额字段用decimal(10,2)而不是float/double，这一点要特别强调：涉及钱的字段用浮点类型会在精度上出问题，Java与MySQL之间还会发生精度损耗，算账差几分钱都够难受的。

3.3 表关系与猫咪状态流转的设计要点

表间关系不复杂：用户和领养申请是一对多；猫咪和领养申请是一对多；用户在申请领养时需要检查自己是否已经申请过同一只猫，避免重复提交；管理员审核通过后，要同时把猫咪的adopt_status从0改成2，这是一个事务操作，丢在同一个@Transactional方法里。

关于猫咪的"已预约"状态，我做了这样一个设计：当用户的申请审核通过、但领养人还没到庄园接猫时，猫的状态设置为"已预约"，此时其他用户在前台仍然能看到这只猫，但详情页会显示"已被申请，待确认"的标记，提交申请时后端也会拦截。猫咪真正被接走后，工作人员把状态改成"已领养"。这个中间状态虽然只多了一个数字，但对线下业务流程的还原度提升很明显。

4. 从接猫到被领养：核心功能模块的实现逻辑拆解

技术选型和表结构定下来后，编码阶段的核心其实是把"业务流程"翻译成"代码逻辑"。这一节我只挑最有代表性的几个模块讲清楚，每个模块怎么写、为什么这样设计。

4.1 文件上传与图片访问映射

猫咪档案必须有图，否则领养人很难产生好感。图片上传逻辑本身不难，但有一个细节经常被忽略：上传后的图片路径映射。

Springboot默认只能访问classpath:/static/下的静态资源，如果你把图片传到服务器本地磁盘的某个目录（比如/home/ubuntu/cat_image/），前端访问不到。需要写一个WebMvcConfigurer把磁盘路径映射为URL路径：

java复制@Configuration
public class WebConfig implements WebMvcConfigurer {
    @Override
    public void addResourceHandlers(ResourceHandlerRegistry registry) {
        String imagePath = System.getProperty("user.dir") + File.separator
                + "upload" + File.separator;
        registry.addResourceHandler("/upload/**")
                .addResourceLocations("file:" + imagePath);
    }
}

这样图片放在项目运行目录的upload文件夹下，浏览器访问http://localhost:8080/upload/xxx.jpg就能直接打开。另外，我在上传接口里还做了文件类型白名单校验（.jpg、.png、.gif），防止有人上传jsp等危险文件；大小限制设定为5MB，通过Spring的spring.servlet.multipart.max-file-size=5MB配置控制。

4.2 领养审核流程：状态机思维与事务控制

领养审核是这套系统里业务逻辑最重的模块，我把它拆成三个接口：

• 用户提交申请：POST /api/apply
• 管理员查看待审核列表：GET /api/admin/apply/list?status=0
• 管理员审核：POST /api/admin/apply/audit

提交申请的代码逻辑如下：

java复制@Override
@Transactional(rollbackFor = Exception.class)
public boolean submitApply(ApplyDTO dto, Long userId) {
    // 1. 校验猫是否存在且处于待领养状态
    CatInfo cat = catInfoMapper.selectById(dto.getCatId());
    if (cat == null) {
        throw new BizException("猫咪不存在");
    }
    if (cat.getAdoptStatus() != 0) {
        throw new BizException("该猫咪当前不可申请领养");
    }

    // 2. 校验同一用户同一猫只能申请一次
    LambdaQueryWrapper<AdoptApply> wrapper = new LambdaQueryWrapper<>();
    wrapper.eq(AdoptApply::getUserId, userId)
           .eq(AdoptApply::getCatId, dto.getCatId());
    Long count = adoptApplyMapper.selectCount(wrapper);
    if (count > 0) {
        throw new BizException("您已申请过该猫咪，请勿重复提交");
    }

    // 3. 保存申请记录
    AdoptApply apply = new AdoptApply();
    BeanUtils.copyProperties(dto, apply);
    apply.setUserId(userId);
    apply.setStatus(0);
    adoptApplyMapper.insert(apply);

    // 4. 猫的状态变成"已预约"
    cat.setAdoptStatus(1);
    catInfoMapper.updateById(cat);
    return true;
}

审核接口要处理的状态更多：管理员点"通过"，则申请状态变为1，猫的状态保持或更新为2；管理员点"驳回"，则申请状态变为2，猫的状态要回退为0（待领养），因为申请不通过意味着这只猫还继续对外展示。这里最容易漏掉的坑就是：驳回时忘了把猫的状态改回去，导致一只明明没人领养的猫在前台一直显示"已预约"。

4.3 数据看板：用SQL聚合代替低效的循环统计

首页看板是系统给管理员的第一印象，我做了四个指标卡片：猫只总数、待领养数、待审核申请数、本月捐赠总额，外加一个用ECharts渲染的最近6个月捐赠金额柱状图。

前三个指标的统计直接使用MyBatis-Plus的selectCount配合LambdaQueryWrapper；捐赠总额用了聚合查询：

java复制LambdaQueryWrapper<DonationRecord> wrapper = new LambdaQueryWrapper<>();
wrapper.select(DonationRecord::getAmount)
       .between(DonationRecord::getCreateTime, start, end);
List<DonationRecord> list = donationRecordMapper.selectList(wrapper);
BigDecimal total = list.stream()
       .map(DonationRecord::getAmount)
       .reduce(BigDecimal.ZERO, BigDecimal::add);

如果数据量很大，应该用SELECT SUM(amount)在数据库端完成，但考虑到庄园系统每天也就几十条捐赠记录，先把数据查出来再用Java聚合是没问题的。这里更值得强调的是：前端图表数据不是一个框架自动生成的，需要自己写一个统计接口返回JSON格式的数据，前端再用ECharts渲染。做毕设的同学遇到"图表怎么显示出来"这个问题时，先抓接口返回的数据结构，再抓前端渲染逻辑，问题就清晰了。

4.4 登录认证：JWT + 拦截器实现轻量权限控制

管理后台不能裸奔，需要一个基础的登录认证。我选用JWT而不是Spring Security的完整方案，原因是这个项目的权限模型只有"登录用户"和"管理员"两类，用Security要配置一大套，项目里反而显得重。

认证流程如下：

1. 登录接口校验用户名密码，成功后用用户ID和用户名生成JWT Token返回前端
2. 前端把Token存在localStorage中，每次请求在请求头里带Authorization: Bearer xxx
3. 后端写一个AuthInterceptor拦截器，在preHandle中解析Token，解析成功则放行，失败则返回401
4. 对于/admin/**路径，额外校验Token中携带的角色是否是管理员

用JWT有几个好处：服务端无状态、不需要存session、前端和后端分离时也好用。但要注意token的有效期设置，我设置的是24小时，太短会导致用户频繁重新登录，太长又不安全。

提示：JWT的原理是服务端用密钥对信息签名，前端拿到的token无法被篡改，但token本身是Base64编码的，明文部分不要放密码、手机号等敏感信息。

4.5 前端页面与交互设计上的取舍

前端我选择了Thymeleaf模板引擎加Bootstrap框架，没有做前后端分离。这个选择是经过考量的：做毕设的核心是展示业务逻辑，用Thymeleaf可以直接在页面中通过th:each等标签渲染数据，后端接口和页面在一个工程里，部署时只需要打一个jar包，不会出现跨域、Nginx配置这类额外问题。

页面设计上，前台首页是猫咪展示墙，采用卡片式布局，每张卡片上显示猫咪照片、名字、品种和领养状态；后台管理界面采用左侧菜单栏加右侧内容区的经典布局。整个前端不需要多惊艳，保持干净、整洁、操作路径清晰即可，评分老师更看重功能完整性和业务闭环。

5. 调试部署实战：本地运行到发布上线的完整踩坑记录

很多同学写代码是一回事，部署运行又是另一回事。代码在本地一切正常，换个环境就各种报错。这章把调试部署过程中遇到的高频问题按场景拆开，并给出排查思路，而不是直接给答案。

5.1 数据库环境配置：时区、驱动、连接池一个都不能少

本地开发时我用的MySQL 8.0，JDBC连接配置如下：

yaml复制spring:
  datasource:
    driver-class-name: com.mysql.cj.jdbc.Driver
    url: jdbc:mysql://localhost:3306/cat_manor?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false
    username: root
    password: 123456
    type: com.alibaba.druid.pool.DruidDataSource

三个容易被忽略的点：

• driver-class-name在MySQL 8.x必须写com.mysql.cj.jdbc.Driver，之前的com.mysql.jdbc.Driver会提示过时或报错
• serverTimezone不设置时，时间字段的读写可能会差8个小时，特别是用LocalDateTime类型时很明显
• 用Druid数据源时，pom里引入的是druid-spring-boot-starter而不是druid，否则Spring容器无法自动配置Druid监控和连接池

5.2 项目能启动但访问页面报404/500的排查思路

我在测试过程中遇到一个经典问题：后台管理页面/admin访问跳转到登录页后，登录成功却一直停留在登录页，控制台也没有报错。排查链路大致如下：

先看拦截器是否放行了登录接口和静态资源。如果拦截器把/admin/login请求也拦截了，登录请求根本到不了Controller，前端拿到401后自然无法跳转。我在AuthInterceptor里加入了白名单数组：

java复制private static final String[] ALLOW_PATHS = {
    "/", "/index", "/cat/detail/**", "/user/login", "/user/register",
    "/admin/login", "/upload/**", "/error"
};

再看登录成功后跳转的接口是否返回了页面片段而不是完整页面。用Thymeleaf时，Controller返回的字符串要能匹配到templates目录下的模板文件，如果返回的路径写错了，会直接抛TemplateInputException，这个异常信息其实很明确，但很多人被页面上"Whitelabel Error Page"迷惑了，没有往下看日志。

5.3 打包部署：用Maven打jar包，服务器上一条命令跑起来

开发完成后，项目的部署方式我选择了可执行jar包，不额外装Tomcat。步骤很简单：

bash复制mvn clean package -DskipTests

打包产物在target/cat-manor-0.0.1-SNAPSHOT.jar。上传到服务器后，如果服务器只装了JDK 1.8和MySQL，直接执行：

bash复制java -jar cat-manor-0.0.1-SNAPSHOT.jar

后台运行可以用：

bash复制nohup java -jar cat-manor-0.0.1-SNAPSHOT.jar --server.port=8080 > catalina.log 2>&1 &

启动后通过http://服务器IP:8080访问。如果访问不通，先检查云服务器的安全组是否放行了8080端口，再检查防火墙；本地则用curl http://localhost:8080确认服务有没有起来。这一步90%的问题出在网络策略上，而不是代码本身。

还有个小细节：Springboot默认的端口是8080，如果服务器上已经跑了别的Java应用，端口冲突会直接报Port 8080 was already in use，换一个端口或用--server.port参数指定即可。

5.4 从开发环境到演示环境的"最后一公里"检查清单

每次准备演示或交付前，我都会按照这张表过一遍，能拦住绝大多数现场翻车：

把这张表贴在工位上，每次演示前过一遍，至少能避免一半的尴尬。

6. 万字论文文档怎么组织：结构、图表与答辩要点

这套系统有一个很现实的需求：需要配套一篇1万字以上的论文文档。很多同学代码敲得还不错，一写论文就抓瞎。我这里结合自己写作时的实际经验，把论文的核心结构和每章要写什么讲清楚。

6.1 论文的七章结构及各章写作重点

我采用的论文结构是高校计算机类毕设最常见的模式，但也做了一些针对系统本身的调整：

第一章绪论：写选题背景（流浪动物数量增长、救助站信息化水平低）、国内外研究现状、研究目的与意义。注意不要大段抄百度百科，要结合具体场景说问题。

第二章相关技术介绍：Springboot框架简述、MyBatis-Plus说明、MySQL数据库介绍、前端技术栈。这一章是凑篇幅的大户，但要控制在一页到两页，技术介绍的篇幅占比过高会被老师认为凑字数。

第三章系统分析：可行性分析（技术可行性、经济可行性、操作可行性）、需求分析（功能性需求、非功能性需求）、用例分析。这一章要画出用例图，至少要包含管理员和普通用户两个角色分别有哪些操作权限。

第四章系统设计：系统总体架构图、功能模块设计、数据库设计（ER图、表结构说明）。数据库设计这块要详细展开，每个表的字段含义、表间关系都要说清楚，这是评阅老师重点看的内容。

第五章系统实现：按模块描述实现过程，每个模块配2-3段核心代码和运行截图，文字说明实现逻辑。注意代码不能全贴，要选有代表性的，比如领养审核、图片上传、权限拦截。

第六章系统测试：功能测试用例表、测试结果分析。用表格把每个功能模块的测试用例列出来，包括测试数据、预期结果、实际结果、是否通过。

第七章总结：写过程中遇到的问题、解决方法、系统不足和展望。这里要写得真诚一点，不要写"系统功能完善、性能优越"这种空话，也不要贬低自己的代码。写"本系统实现了流浪猫庄园日常管理的核心流程，但在移动端适配和消息推送方面仍有改进空间"这样的表述更有说服力。

6.2 画图工具与图表规范

论文里一定要有图，图的专业程度直接影响老师的第一印象。ER图、用例图、时序图我推荐用ProcessOn或者draw.io画；架构图、功能结构图用Visio或ProcessOn都行；流程图可以用draw.io的场景模板。图的风格要统一，建议全部用同一种颜色主题，不要一张彩色一张黑白。

图下面要加图注，格式为"图5-1 用户领养申请流程图"，表上方要加表题，格式为"表6-1 猫咪信息管理模块测试用例"。

6.3 答辩时容易被追问的几个问题

论文写完后，答辩环节也要提前准备。根据我参加过的答辩和帮人模拟答辩的经验，评阅老师最常追问的点集中在：

• 为什么选择这个课题？——结合亲身经历或社会观察说，不要只说"因为这个技术比较火"
• 系统有哪些创新点？——如果功能上没有太亮眼的创新，可以说"系统的业务场景贴合流浪动物救助实际需求，通过状态流转机制实现了从救助到领养的全流程追踪"
• 数据库表为什么这样设计？——从三范式、业务需求、查询效率三个角度回答
• 遇到的最大困难是什么？——说具体的技术问题，如"图片上传后无法访问，通过配置静态资源映射解决"，比空泛说"遇到了一些问题"强得多

记住一个原则：答辩考察的是你对自己项目的理解程度。代码可以是自己一行行敲的，论文可以慢慢磨，但对业务的思考深度是装不出来的，踏踏实实把每个模块为什么这么设计想明白，答辩基本就不会出大问题。

结尾

这套系统从构思到基本成型，我前后花了三周多时间，真正写代码的时间其实还好，大部分精力花在了数据库设计的前后反复和部署环境的各种排错上。有一次为了排查"列表页能打开但图片全裂"，一路从Thymeleaf模板查到了静态资源映射配置，最后发现是路径拼接少了一个斜杠。这类问题听起来很小，实际排查却最耗时，也是最有价值的学习过程。

如果你也想动手做一套类似的Springboot管理系统，我的建议是拿到题目后先别急着写代码，把自己当成真实的庄园管理员，把业务场景里每天要发生的事情在纸上过一遍，再动手设计表和接口。这个过程想通了，后面的开发其实是水到渠成的事。