SpringBoot流浪动物救助平台毕设：从表设计到Docker部署-代码聚汇网

1. 毕设选题拆解：流浪动物救助平台到底在做什么

每年毕业季，SpringBoot选题里总有几个“常青树”：外卖系统、商城系统、图书管理、酒店预订，流浪动物救助平台也算其中之一。这个题目乍一看很像普通的CRUD管理系统，但实际做起来会发现，它比图书管理多了“业务状态流转”，比商城系统少了“支付闭环”，属于那种难度适中、又能在答辩时有东西可讲的题目。

先说清楚这个平台的核心业务边界，这直接决定你项目中的模块拆分和数据库设计。

流浪动物救助平台，本质上是一个连接三方角色的信息中介：流浪动物发现者（普通用户）提交求助信息、救助站（管理员）审核并处理救助请求、潜在领养人（普通用户）浏览待领养动物并发起领养申请。除此之外，还至少要包含宠物档案管理、领养审核、回访记录、公告发布、站内留言这些贴近实际需求的辅助功能。

很多学生拿到这个题目第一反应是“做一堆页面”，其实错了。毕设答辩时老师最在意的是你有几条完整的业务链路，而不是你有多少个页面。比如用户提交求助后，管理员如何受理、状态如何从“待审核”变成“处理中”再到“已完成”，这条链路能闭环，就比做二十个静态页面有价值得多。

我第一次带学生做这个题目时，最常遇到的坑是：数据表设计得过于简陋，把“领养申请”和“领养审核记录”混在一张表里，导致后面写领养状态流转时代码越写越乱，最终只能推倒重来。所以这篇文章第一篇内容，先聚焦在项目启动前的需求分析和表结构设计上，这部分定了，后面写代码会顺畅很多。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 表结构设计：救助平台的数据底座长什么样

数据表设计是这种管理类系统的地基。地基不稳，后面Service层写多复杂都会觉得别扭。我按照最常见的业务拆分方式，把核心表拆成“用户相关”“业务相关”“内容相关”三组，每组的作用单独理清。

2.1 用户体系：不要只做一张user表

很多毕设做用户模块就建一张user表，字段是username、password、role，然后通过role区分管理员和普通用户。这种设计应付简单场景没问题，但流浪动物救助平台里，普通用户和管理员拥有的字段差异很大，硬塞进一张表会出现大量null字段，看起来很乱。

我建议拆成两张表：t_user（普通用户）和t_admin（管理员）。普通用户存id、用户名、密码、昵称、手机号、地址、注册时间、头像、状态，管理员只存id、用户名、密码、角色标识、最后登录时间。这样在Spring Security或者JWT做登录鉴权时，两个主体分开查询、分开处理，逻辑上更清晰。

如果你想让项目更有东西可讲，可以在t_user表加一个“积分”字段，用户通过提交有效救助信息、成功领养宠物获得积分，积分可以在积分商城兑换猫粮狗粮。这个设计属于业务微创新，答辩时提到“用积分提升平台活跃度”这种思路，很容易让老师觉得你有产品思维，而不仅仅是会写增删改查。

2.2 业务核心表：救助与领养的状态流转

业务核心表有四张：t_rescue_apply（救助申请）、t_pet（动物档案）、t_adopt_apply（领养申请）、t_follow_up（回访记录）。

t_rescue_apply是用户上报流浪动物信息的申请单，核心字段包括：申请人ID、动物类型、所在位置、情况描述、图片URL、紧急程度、状态。状态字段要好好设计，我推荐用整数枚举而不是字符串，比如0-待审核、1-审核通过待救助、2-救助完成、3-已驳回。用整数枚举配合后端常量类，查询效率高，写代码时也不容易拼错字符串。

t_pet是救助完成之后建立的动物档案，一旦救助站确认某只流浪动物被妥善接收，就为它创建档案。字段包括宠物名称、品种、年龄、性别、是否绝育、疫苗情况、健康状态、性格描述、照片、当前状态（0-待领养、1-已被申请、2-已领养、3-休养中）、所在救助站。这张表的记录会展示在平台首页的“待领养宠物”列表里，所以图片字段、描述字段的完整性很重要。

t_adopt_apply是用户发起领养申请的记录，核心字段：申请用户ID、宠物ID、申请时填写的居住情况、养宠经验、申请理由、状态（0-待审核、1-审核通过、2-已领养、3-已拒绝、4-已取消）。这里要特别注意，当领养申请审核通过后，t_pet表里对应宠物的状态要同步更新为“已被申请”，避免多个用户同时领养同一只宠物造成数据错乱，这个联动逻辑在答辩时是加分点。

t_follow_up是回访记录表，用于记录领养成功后的定期回访情况，字段包括：领养记录ID、回访时间、回访内容、回访人，这是很多同类毕设会忽略、但非常“懂行业”的一张表，能够体现你对业务的完整理解。

2.3 辅助表：公告、留言、收藏

辅助功能不建议做太多，但有三张表非常推荐加上，性价比高、实现简单、又能丰富业务场景。

t_notice公告表，管理员发布平台公告，字段就是标题、内容、发布时间、是否置顶。首页轮播图和公告栏都能用这张表的数据填充。

t_message站内留言表，用户给救助站留言咨询问题，管理员可以在后台回复。字段包括：发送人ID、接收人类型、内容、回复内容、发送时间、回复时间。

t_favorite收藏表，用户可以收藏自己感兴趣的待领养宠物，方便日后再次查看。字段就三个：用户ID、宠物ID、收藏时间。

这三张表实现起来都是标准的单表CRUD，但加进系统里，后台管理菜单会丰富很多，演示系统时整体功能覆盖面也更完整。表结构设计的原则是先画核心链路，再补外圈功能，不要一上来就想做积分商城、论坛这种大而全的东西。

3. 技术选型背后的取舍：为什么是SpringBoot + Vue，而不是微服务

技术选型是开题报告里老师一定会问的问题。网上很多模板喜欢堆一堆技术名词——SpringCloud、Redis、RabbitMQ、ElasticSearch，堆得越多越显得厉害。但我想说，毕设阶段技术选型的核心原则是：能稳定跑通、能自圆其说、面试能答上来。

3.1 后端为什么选SpringBoot而不是SpringCloud

SpringBoot的优点不用多说：自动装配简化配置、内嵌Tomcat开箱即用、生态完善第三方集成方便。对于单体应用的毕业设计来说，SpringBoot足够支撑所有业务场景。

SpringCloud是为微服务架构设计的，如果只有一个后台服务加一个前台服务，拆微服务纯属自找麻烦。同学你要想清楚，拆微服务之后要面对服务注册与发现、配置中心、网关、分布式事务等一系列问题，每一个都是答辩时可能被追问的无底洞。

选SpringBoot还有一个现实原因：网上资料多，遇到问题容易搜到解决方案。MyBatis映射文件报错、拦截器配置失效、文件上传大小限制，这些问题随便一搜都有现成答案。如果选了一个冷门框架，卡住一天没人答疑，心态很容易崩。

SpringBoot版本建议选2.7.x或者3.0.x，不要追求最新。有些时候太新的版本刚发布，第三方starter的兼容性还没跟上，反而会把项目搞挂。这个经验也是很多学生踩坑后总结出来的，后面部署章节我会详细说。

3.2 前端用Vue还是Thymeleaf

这里有两条路可选。

第一条路是传统的SpringBoot整合Thymeleaf，前后端不分离，页面由后端渲染，写完直接访问。优点是结构简单，部署方便，不需要处理跨域问题；缺点是页面交互体验一般，动态渲染部分需要依赖模板引擎语法，写起来不如Vue顺手。

第二条路是前后端分离，后端提供RESTful API，前端用Vue + Element UI（或者Vue 3 + Element Plus）写页面，通过Axios请求数据。优点是前后端职责清晰，前端页面可以做得很精致，Vue的组件化开发写起来也舒服；缺点是部署时要分别处理前端dist目录和后端jar包，还要解决跨域配置。

从毕业设计演示效果和简历含金量来看，我更推荐前后端分离。答辩时你可以说“前端采用Vue进行组件化开发，后端提供统一的REST API，通过Axios进行数据交互，使用JWT实现无状态认证”，这一句话就能体现你对现代Web开发的理解。

如果你对前端不熟，Vue这块也不需要学得很深，掌握这几个就够用了：Element UI常用组件（表格、表单、弹窗、菜单）、Vue Router路由配置、Axios请求封装。别去啃Vuex全家桶，用不上。在后端接口那边做好数据返回格式统一，前端写起来会非常轻松。

3.3 数据库选型与ORM框架

数据库用MySQL，这个选择基本是定论，考试、面试、工作都在用，社区资料也最丰富。MySQL版本建议5.7或8.0，5.7兼容性最好，8.0功能更新，如果对版本不敏感就选5.7，碰到网上教程时匹配度更高。

ORM框架首选MyBatis-Plus，这是国内Java开发的事实标准。MyBatis-Plus在MyBatis基础上提供了BaseMapper通用方法，单表CRUD连SQL都不用写；分页插件、代码生成器、条件构造器这些工具也非常适合毕设这种“快速产出、大量重复CRUD”的场景。

如果你的项目里要写复杂多表关联查询，MyBatis-Plus也支持自定义XML映射文件，灵活度足够。

表结构设计得好的前提下，MyBatis-Plus能让你少写至少30%的样板代码。我把话放这儿，任何跟你说“用MyBatis手写SQL锻炼能力更好”的人，大概率没经历过半夜赶进度的痛。

4. 核心功能从0到1：领养审核状态机与文件上传

功能实现部分，我挑两个最核心、也最容易在答辩时被深入追问的点展开：领养审核的状态流转逻辑，以及图片文件的上传与访问映射。这两个点一个是业务逻辑的内核，一个是基础设施的必备。

4.1 领养审核状态流转：用状态枚举代替魔法数字

领养审核是整个平台业务逻辑最复杂的模块，没有之一。它的核心本质是一个状态机。

用户的视角是：浏览宠物列表、看到心仪的宠物、提交领养申请、等待审核、审核结果通知。

管理员的视角是：收到新申请、查看申请资料、联系申请者并审核、通过或拒绝。

我建议设计一个AdoptStatusEnum枚举类，把申请状态集中管理起来：

java复制public enum AdoptStatusEnum {
    PENDING(0, "待审核"),
    APPROVED(1, "审核通过"),
    ADOPTED(2, "已领养"),
    REJECTED(3, "已拒绝"),
    CANCELED(4, "已取消");

    private final Integer code;
    private final String desc;

    AdoptStatusEnum(Integer code, String desc) {
        this.code = code;
        this.desc = desc;
    }

    public Integer getCode() {
        return code;
    }

    public String getDesc() {
        return desc;
    }

    public static String getDescByCode(Integer code) {
        for (AdoptStatusEnum value : values()) {
            if (value.code.equals(code)) {
                return value.desc;
            }
        }
        return "未知状态";
    }
}

有了状态枚举，Service层写业务逻辑时就不会出现到处都是裸的数字0、1、2。核心方法大概长这样：

java复制@Service
public class AdoptApplyServiceImpl implements AdoptApplyService {

    @Override
    @Transactional(rollbackFor = Exception.class)
    public void approveAdopt(Long applyId) {
        AdoptApply apply = adoptApplyMapper.selectById(applyId);
        if (apply == null) {
            throw new BusinessException("申请记录不存在");
        }
        if (!AdoptStatusEnum.PENDING.getCode().equals(apply.getStatus())) {
            throw new BusinessException("当前状态不可审核");
        }
        apply.setStatus(AdoptStatusEnum.APPROVED.getCode());
        apply.setAuditTime(new Date());
        adoptApplyMapper.updateById(apply);

        // 同步更新宠物状态为“已被申请”，避免其他人重复申请
        Pet pet = petMapper.selectById(apply.getPetId());
        if (pet != null && PetStatusEnum.AVAILABLE.getCode().equals(pet.getStatus())) {
            pet.setStatus(PetStatusEnum.APPLIED.getCode());
            petMapper.updateById(pet);
        }
    }
}

看到没有，所谓“状态机”没有玄乎的东西，它就是状态有约束地迁移。审核通过只允许在“待审核”状态发生，已经取消的申请不能再审核，已经领养的宠物不能再发起申请。你在写代码时把这些约束通过枚举和if判断体现出来，代码的健壮性立刻提升一个档次，这在答辩时也是老师最容易肯定你的点。

再补充一个细节：为什么approveAdopt方法要加@Transactional？因为审核通过要同时修改“申请状态”和“宠物状态”两张表的数据，要么都成功，要么都回滚。不加事务的话，可能出现申请显示通过、宠物状态却没更新的脏数据，这个坑我见过太多次了。

4.2 文件上传与静态资源映射：让图片能存也能看

流浪动物平台必然涉及图片上传——救助信息要传现场照片、宠物档案要传萌照、用户头像也要传。文件上传功能的实现本身不难，但有两个坑会让新手卡很久：一个是文件大小限制导致上传报错，另一个是上传成功后页面访问不到图片。

SpringBoot的文件上传，核心代码写在Controller里：

java复制@PostMapping("/upload")
public Result<String> upload(MultipartFile file) {
    if (file.isEmpty()) {
        return Result.error("上传文件不能为空");
    }
    String originalFilename = file.getOriginalFilename();
    String suffix = originalFilename.substring(originalFilename.lastIndexOf("."));
    String fileName = UUID.randomUUID().toString().replace("-", "") + suffix;

    // 按日期分目录存储，避免单个目录文件过多
    String datePath = new SimpleDateFormat("yyyy/MM/dd").format(new Date());
    String dirPath = uploadDir + "/" + datePath;
    File dir = new File(dirPath);
    if (!dir.exists()) {
        dir.mkdirs();
    }
    file.transferTo(new File(dirPath + "/" + fileName));

    String url = "/files/" + datePath + "/" + fileName;
    return Result.success(url);
}

这里有两个要点需要解释。

第一，文件名用UUID重命名，避免用户上传“流浪狗.jpg”这种中文文件名导致的URL编解码问题；同时保留原文件后缀，防止图片格式丢失。

第二，按日期分目录存储，单日文件量大的话不会让一个目录下堆几万个文件，Linux文件系统在单个目录文件过多时访问性能会下降，虽然毕设阶段可能到不了这个量级，但好的习惯要从一开始养成。

上传的图片要能被浏览器访问，需要配置资源映射，在application.yml里加上：

yaml复制spring:
  servlet:
    multipart:
      max-file-size: 10MB
      max-request-size: 20MB

再加一个WebMvc配置类：

java复制@Configuration
public class WebMvcConfig implements WebMvcConfigurer {

    @Value("${file.upload-dir}")
    private String uploadDir;

    @Override
    public void addResourceHandlers(ResourceHandlerRegistry registry) {
        // 将本地的 /files/** 映射到磁盘的 uploadDir 目录
        registry.addResourceHandler("/files/**")
                .addResourceLocations("file:" + uploadDir + "/");
    }
}

有一点一定要提醒：uploadDir在Windows和Linux上路径写法不一样，Windows下是D:/upload/，Linux下是/home/ubuntu/upload/。为了不踩平台的坑，建议把路径配置写在application.yml里，通过@Value注入，不要在代码里写死。这样部署到服务器时只需要改配置，不用重新编译代码。

4.3 权限控制：让普通用户进不了后台

救助平台天然有两种角色，管理员和普通用户。管理员能进后台管理页，能审核申请，能发公告；普通用户只能在前台页面浏览、提交申请。这个需求要靠后端接口权限控制落地。

推荐用SpringBoot拦截器加自定义注解的方式实现权限控制，简单、轻量、够用，比引入Spring Security再配置一堆过滤链要省心得多。

先写一个@RequireAdmin注解，标注在需要管理员权限的接口上：

java复制@Target({ElementType.METHOD, ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
public @interface RequireAdmin {
}

再写一个拦截器，在请求进入Controller之前校验当前登录用户的角色：

java复制@Component
public class AdminAuthInterceptor implements HandlerInterceptor {

    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) 
            throws Exception {
        if (handler instanceof HandlerMethod) {
            HandlerMethod handlerMethod = (HandlerMethod) handler;
            RequireAdmin requireAdmin = handlerMethod.getMethodAnnotation(RequireAdmin.class);
            if (requireAdmin != null) {
                // 从request中获取当前登录用户，由登录拦截器提前放入
                User currentUser = (User) request.getAttribute("currentUser");
                if (currentUser == null || !"ADMIN".equals(currentUser.getRole())) {
                    response.setStatus(403);
                    response.setContentType("application/json;charset=UTF-8");
                    response.getWriter().write("{\"code\":403,\"msg\":\"无权限访问\"}");
                    return false;
                }
            }
        }
        return true;
    }
}

这里的关键思路是：登录拦截器负责“你是谁”，管理员拦截器负责“你能干什么”。两个拦截器职责分开，登录逻辑和管理员校验逻辑互不嵌套，后期改起来也方便。

JWT登录方案也是同样原理。用户登录成功后后端生成一个Token，前端每次请求把Token放在Header里传回来，登录拦截器解析Token并放用户信息到Request中，再去判断是否需要管理员权限。整个链路只要理顺了，写起来其实很快。

5. 答辩前必须讲清楚的两个SpringBoot原理问题

毕设答辩时，老师大概率会从你的项目里抽出两个“底层原理”问题来考查你是真正理解框架，还是只会使用框架。流浪动物救助平台这种项目，最有可能被问到的是SpringBoot自动装配原理和事务失效场景。这两个知识点在你简历也完全可以写，属于必会内容，建议认真吃透。

5.1 SpringBoot自动装配：从@SpringBootApplication说起

很多同学用SpringBoot写项目，只知道启动类加个@SpringBootApplication就能跑，但被问“为什么不用写配置文件就能自动配置数据源”时就开始支支吾吾。

自动装配的核心思想可以拆成三步理解。

第一步，@SpringBootApplication是一个组合注解，它包含了@SpringBootConfiguration、@EnableAutoConfiguration、@ComponentScan三个注解。其中最关键的是@EnableAutoConfiguration。

第二步，@EnableAutoConfiguration通过@Import(AutoConfigurationImportSelector.class)导入了自动配置选择器。这个选择器做的事情是：扫描所有jar包中META-INF/spring.factories文件里配置的EnableAutoConfiguration全类名列表。我们引入的spring-boot-starter-web、mybatis-plus-boot-starter这些starter里都带了自己的spring.factories文件，里面记录了需要自动装配的配置类。

第三步，Spring容器会尝试加载这些配置类，但并不是“无脑全加载”。配置类上往往带有@ConditionalOnClass、@ConditionalOnMissingBean、@ConditionalOnProperty之类的条件注解。比如DataSourceAutoConfiguration上就有@ConditionalOnClass({DataSource.class, EmbeddedDatabaseType.class})，意思是只有在classpath下能找到DataSource相关的类时，它才会去自动配置数据源。

一句话总结自动装配的本质：配置类都提前定义好了，是否启用取决于类路径中的依赖和条件注解的判断结果。你用MyBatis-Plus做数据访问层，类路径里有相关的包和配置，SpringBoot就自动帮你把数据源配好；你不在pom里引它，再怎么自动装配也找不到对应的类。

给同学一个答辩时的表述建议：“SpringBoot的自动装配是一种约定优于配置的实现，starter通过SPI机制在spring.factories里注册配置类，再由条件注解按需装配，本质上是把‘手动配置’变成了‘按需启用’。”这个回答既有术语又有深度，比背概念强得多。

5.2 事务失效的常见场景：为什么update没生效

事务失效是Spring面试的高频题，也是你项目里很容易埋雷的地方。我总结几个流浪动物救助平台里最常见的场景。

第一个是方法内部自调用。比如AdoptApplyServiceImpl里，一个方法调用了同一个类里的另一个事务方法，事务直接失效。因为Spring事务是基于AOP代理的，自调用走的是this而不是代理对象，切面不生效。

解决方式有两种：把被调用的方法拆到另一个Service类里；或者注入自身代理对象@Autowired private AdoptApplyService self;然后self.otherMethod()调用。

第二个是@Transactional加在非public方法上。Spring默认只对public方法拦截，加在private方法上，注解直接不起作用。

第三个是事务方法内部捕获了异常。看到很多同学写代码喜欢用try-catch把所有异常吞掉，这意味着事务方法执行完看起来是成功了，但底层SQL已经报错了，事务自然无法回滚。

java复制@Transactional
public void approveAdopt(Long applyId) {
    try {
        // 业务代码
        apply.setStatus(1);
        adoptApplyMapper.updateById(apply);
    } catch (Exception e) {
        e.printStackTrace();
        // 异常被吞掉了，事务不会回滚
    }
}

正确写法是：让事务方法把异常抛出去，由外层统一处理，或者在catch块里手动设置TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()强制回滚。

答辩时关于事务失效，你只要能把“自调用”“非public方法”“异常被吞”这三个场景讲清楚，面试官就会认为你有实际项目经验，而不是背了几道面经。因为这些细节一定是在真实项目踩坑后才能总结出来的。

5.3 循环依赖：Spring的三级缓存是怎么回事

SpringBoot项目里另一个高频考点是循环依赖。比如RescueService依赖PetService，PetService又依赖RescueService，两个Bean互相引用，启动时就会报出循环依赖异常。

Spring解决循环依赖靠的是三级缓存。一级缓存singletonObjects放成品Bean，二级缓存earlySingletonObjects放早期暴露的半成品Bean，三级缓存singletonFactories放对象工厂。

简化理解：Bean A创建时，先把自己“工厂”放进三级缓存；创建过程中发现需要注入Bean B，就去创建Bean B；Bean B又需要注入Bean A时，此时A虽然没有创建完成，但三级缓存里已经有A的工厂了，B可以提前拿到A的引用（早期对象）继续完成创建；B创建完成后，A再通过注入工厂生成的A对象完成自己的创建，最后A和B都进入一级缓存，它们引用的实际是同一个A对象。

不过，SpringBoot 2.6以后的版本默认禁止了循环依赖，启动时直接报错。原因很简单：循环依赖是一种设计坏味道，很多复杂的循环现象背后往往是职责边界没理清。

对于你的项目，我的建议是最佳实践不要使用循环依赖。如果真出现两个Service互相调用的场景，优先重构业务逻辑，把重叠的部分抽到第三个Service里，或者通过事件机制解耦，让代码结构更清晰。答辩时如果你能说出“新版SpringBoot默认禁用循环依赖，我通过重构避免了这种设计”，这个回答非常加分，体现了你既懂原理又懂工程实践。

6. Docker打包部署：从本机到服务器的一站式方案

毕设做到最后一步，很多同学的交付物就是一个跑在本机的SpringBoot项目。如果老师让你现场演示，结果你只能在IDE里点Run，这其实是个减分项。提前把项目打成可运行jar包，再用Docker部署到云服务器，演示时直接访问公网地址，这个体验和“本地演示”截然不同。

6.1 环境准备：JDK版本和Docker Desktop的坑

先说一个大家经常踩的坑：本地开发环境JDK版本过高，和SpringBoot版本不匹配。

比如你本地装的是JDK 17，却选了个SpringBoot 2.3版本，启动时会报UnsupportedClassVersionError，因为SpringBoot 2.3是基于JDK 8编译的，在JDK 17环境下会有兼容性问题。

常规组合建议：SpringBoot 2.7.x配JDK 8或JDK 11；SpringBoot 3.0.x要求JDK 17以上。如果你要打包到Docker容器，镜像里的JDK版本也要尽量和开发环境保持一致，别开发环境用JDK 17、服务器镜像用openjdk:8，这样打出来的jar包大概率跑不起来。

Docker Desktop在Windows和Mac上安装时，最容易忽略的是内存分配。Windows上开着WSL2后端，默认内存可能只有2GB，跑MySQL加SpringBoot两个容器就卡得不行。建议在Docker Desktop的Settings -> Resources里把内存调整到4GB以上，这个操作简单但非常有效。

6.2 打jar包的姿势：跳过测试和静态资源路径

打包之前，先在pom.xml确认spring-boot-maven-plugin没有缺失。然后执行：

bash复制mvn clean package -DskipTests

-DskipTests跳过测试，避免因为测试代码不完整导致打包失败。打包完成后，target目录下会生成一个jar包。

这里有一个小细节：打完包后启动时，如果出现端口被占用的报错，多半是本地开着相同端口。启动命令改为：

bash复制java -jar xx.jar --server.port=8081

如果用到文件上传功能，本地IDE里配置的资源路径和jar包运行时的工作目录不同，一定要确保application.yml中的file.upload-dir路径是绝对路径或者相对于jar包位置的路径，否则“在IDE里能传图片，打成jar包后传不了”的问题就会出现。

6.3 编写Dockerfile和docker-compose

一个简单的SpringBoot应用的Dockerfile可以这样写：

dockerfile复制# 基础镜像，使用JDK 8环境
FROM openjdk:8-jdk-alpine

# 设置工作目录
WORKDIR /app

# 将jar包复制到镜像中
COPY target/help-animal-0.0.1-SNAPSHOT.jar app.jar

# 暴露端口
EXPOSE 8080

# 启动命令
ENTRYPOINT ["java", "-jar", "app.jar", "--spring.profiles.active=prod"]

如果你的项目还需要MySQL数据库，用docker-compose把应用和数据库一起编排起来，一个命令就能全部启动，比手动一个个启动容器省心得多。

yaml复制version: '3'
services:
  mysql:
    image: mysql:5.7
    container_name: help-animal-mysql
    environment:
      MYSQL_ROOT_PASSWORD: root123456
      MYSQL_DATABASE: help_animal
    ports:
      - "3306:3306"
    volumes:
      - mysql-data:/var/lib/mysql
    restart: always

  app:
    build: .
    container_name: help-animal-app
    depends_on:
      - mysql
    ports:
      - "8080:8080"
    environment:
      SPRING_DATASOURCE_URL: jdbc:mysql://mysql:3306/help_animal?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai
      SPRING_DATASOURCE_USERNAME: root
      SPRING_DATASOURCE_PASSWORD: root123456
    restart: always

volumes:
  mysql-data:

这里解释一个概念：depends_on只能保证mysql容器先启动，不代表MySQL服务已经完全可连接。如果应用启动时MySQL还没就绪，应用启动会报“无法连接数据库”。这种情况要么在应用启动命令中加延迟重试机制（比如用一个等待数据库就绪的shell脚本），要么在应用代码里配置连接重试。

对于毕设项目来说，最简单的方案是应用启动前手动等几秒：在docker-compose的app服务entrypoint前加上sleep 20 &&，或者在应用里把数据源的连接重试次数调大。这些方案都不是最佳实践，但足够应付演示场景。

部署完成后，访问http://服务器IP:8080就能看到系统首页。如果有人想看后端API的文档，把SpringDoc或者Swagger集成上，访问/swagger-ui.html就能在线调试接口。答辩时给老师演示这一套，比打开IDE炫代码整整强了一个维度。

7. 源码之外的加分项：把毕设从“能跑”变成“能答辩”

很多同学拿到一套源码，能跑起来就觉得万事大吉。但我想说，毕业设计的评分逻辑是“三看”：一看功能完整性，二看对原理的理解，三看创新点和亮点。源码本身只是基础，你还需要在内容和表述上做一些设计。

7.1 填充“有温度”的演示数据

打开系统后台，如果列表空空如也，老师的第一印象就会打折扣。一定要在部署后手动填充一批贴近真实场景的演示数据。

比如宠物列表里，要有“金毛寻回犬、3岁、已绝育、性格温顺适合有小孩家庭”“中华田园猫、2个月、疫苗已接种、黏人”这种具体描述，而不是“猫”“狗”这种敷衍的数据。

救助申请里，要有不同紧急程度的示例，有“在外流浪数月、尾巴受伤需要治疗”这类有细节的描述，让审核流程演示起来更自然。回访记录里，要有领养后一周、一月、一季度的记录，体现平台对动物后续状况的持续关注。

一定不要在系统里留什么“测试数据1”“张三123”这类明显是赶工期的痕迹。数据的真实性很大程度上影响答辩官对项目的信任程度，这个细节很多人忽略，但很值得做。

7.2 准备一张项目架构图

答辩PPT上放一张清晰的项目架构图，能省下大量解释成本。架构图不需要画得多炫，关键是把技术栈分层表达清楚：前端Vue页面 -> Nginx反向代理 -> SpringBoot应用层 -> Service业务层 -> MyBatis-Plus数据访问层 -> MySQL数据库。另外把文件存储、Redis缓存（如果加了）用独立模块标注出来。

第一张图画整体架构，第二张图可以画领养状态状态机的流转图，具体展示“待审核 -> 审核通过 -> 已领养”的分支路径。这两张图在你答辩时，基本能把80%的技术问题提前堵住。

7.3 答辩讲稿的切入角度

答辩时不要从需求分析开始背，那是开题干的事。建议直接给老师演示一条核心业务链路，比如：“我现在演示一只流浪猫从发现到被领养的全流程。首先模拟用户提交救助申请，管理员在后台审核通过并创建宠物档案，随后该宠物出现在首页待领养列表，用户提交领养申请，管理员审核通过后，宠物状态自动更新，最后在回访模块录入领养人的回访记录。”

这条链路一气呵成，覆盖了平台、救助、领养、回访四个核心模块，而且有前后状态的联动展示，老师很容易看出你系统是完整闭环的，而不是一堆零散的页面拼凑。

之后再针对老师追问的技术问题，从JWT认证流程、自动装配原理、事务处理、Docker部署这些维度展开。把这些细节都准备好，说实话毕业设计答辩基本上就是“稳”了。

7.4 时间规划：不要把你的毕设压缩到一周

最后说点实在的。每年都有学生来跟我讲“老师我下周要交毕设，能不能帮我搞一套源码”，这种临时抱佛脚的状态很难做出真正有质量的系统。

如果你还没开始，我给你一个保守的时间预算：表结构和需求设计花3天，后台管理功能花7天，前台展示和交互花5天，文件上传和权限控制花3天，测试部署和写论文花5天。合计三周左右，这是比较从容的节奏。

如果你已经有了源码想二开，也建议至少留出一周时间：第一天把代码跑通并走读全流程，第二到三天补充或改造功能模块，第四天完善演示数据，第五天部署上线写文档。源码是起点，不是终点。真正到答辩那天，能回答上“为什么这么设计”的，才是你自己的东西。

流浪动物救助平台这个题目，说难不难，说简单也不是纯CRUD。它最妙的地方在于业务上有“救助-建档-领养-回访”这条完整且有社会价值的链路，技术上覆盖了登录鉴权、状态流转、文件上传、部署上线这些出彩点。把这几个环节真正吃透，这套源码带给你的价值远不止一个学分，它可能就是你简历上第一个能拿得出手的完整项目。

SpringBoot流浪动物救助平台毕设：从表设计到Docker部署