企业官网建设流程全解析

1. 为什么这个毕设选题值得做：宠物领养救助系统的现实价值与工作量评估

先说实话，每年毕业设计选题清单里，各类管理系统占了半壁江山，其中宠物领养救助系统又是常青树。道理很简单：这个题目既有完整的业务链路，又贴近日常场景，评委一听就能理解需求，学生也好讲清楚“我做了什么、解决了什么问题”。换句话说，它是一个“性价比”极高的选题。

但千万别以为这是一个普普通通的CRUD系统。认真剥开看，整个业务其实覆盖了两条核心主线：一条是领养流程，从宠物信息发布、用户浏览、在线申请、审核、回访到最终归档；另一条是救助流程，从用户上报流浪动物信息、管理员审核派单、志愿者处理、结果反馈到结案统计。这两条主线互相交错，又都牵涉到用户角色权限、状态流转、信息审核等经典问题，工作量足够撑起一篇像样的毕业论文。

从技术角度看，基于Spring Boot做后端、配合Vue或Thymeleaf做前端，已经是目前毕设圈的标配路线。Spring Boot本身起步快、生态成熟、社区资料多，遇到问题一搜一大把，非常适合在有限时间内完成一个完整项目。如果你愿意在细节上多下功夫，比如引入Redis做缓存、使用MyBatis-Plus简化数据访问、加上JWT实现无状态登录，那么系统在答辩时能呈现出的技术深度会非常可观。

在动手之前，我得先给你提个醒：这个项目最大的难点不是写代码，而是设计好状态流转和权限控制。很多同学一上来就写增删改查，写到一半发现状态对不上、角色权限混乱、流程绕圈，结果只能推倒重来。所以这篇文章里，我会把从需求分析到数据库设计、再到核心代码实现和最终部署调试的完整思路都过一遍，并且会把我在实际开发中踩过的坑一并讲清楚。

无论你是打算拿它做毕业设计，还是想练手一个完整的全栈项目，这篇文章的思路和代码骨架都可以直接参考。

2. 从业务需求到功能清单：先画清楚角色和流程，再谈代码

我见过不少同学拿到这个题目之后，第一件事就是打开IDE创建项目，然后对着空白的Controller发呆。这是典型的“需求没想清楚就动手”。一个靠谱的顺序是：先梳理用户角色，再画业务流程，最后才转化为功能模块和数据库表。

2.1 系统的三类用户角色：普通用户、救助志愿者、管理员

整个系统的用户体系可以分成三层，每一层的职责和权限边界必须清晰。首先是普通用户，也就是访客和注册用户，他们可以浏览待领养宠物列表、查看宠物详情、提交领养申请、发布救助上报信息、在公共区域留言互动。其次是救助志愿者，这是一个相对特殊的角色，他们的核心职责是接收管理员分配的救助工单、上传处理进度和现场反馈，可以理解为“执行层”。最后是管理员，负责全局管理：审核宠物信息、审核领养申请、分配救助工单、管理用户状态、发布公告、查看统计报表。

这里有一个很多初学者容易忽略的点：角色的设计必须和数据权限挂钩。就拿普通用户来说，注册用户只能查看自己的领养申请记录和救助上报记录，不能看到别人的；管理员虽然什么都能看，但也不能在前端页面暴露过于敏感的信息。所以在设计接口时，除了登录态的校验，还要做基于角色的接口访问控制。

2.2 核心业务流程梳理：领养和救助的状态流转

业务流程是整个系统的灵魂，我建议你在一张纸上把两条主线画出来，这里我直接用文字描述。

领养流程是这样的：管理员录入宠物信息并上架，宠物状态为“待领养”；用户看到后提交领养申请，此时申请状态为“待审核”，对应宠物的状态变为“领养审核中”并从前台列表消失或打上标签；管理员审核申请，可以选择“通过”或“驳回”，通过后进入“待回访”阶段，即管理员线下回访用户居住环境确认适合养宠；回访通过，宠物状态改为“已领养”，申请状态改为“已完成”；如果用户在审核期间主动取消，申请状态变为“已取消”。

救助流程则是：用户上报流浪动物信息，生成“待审核”的救助上报；管理员审核通过后创建救助工单，并指派给某个志愿者，工单状态变为“处理中”；志愿者接收后填写处理经过和现场照片，反馈完成后，管理员进行回访确认，最终“结案”；同时，被救助的动物可以进入宠物档案表，经过健康检查和信息完善后，转为待领养宠物，形成业务的闭环。

你看，这两个流程一旦梳理清楚，功能模块呼之欲出，数据库的表结构和状态字段也基本能确定。这也是我想强调的：业务流程设计得越具体，后面写代码和写论文就越省力。

2.3 功能模块划分：前台、后台、管理端一图看清

基于上面的流程，功能模块可以划分成三个部分。

前台展示部分包括：首页轮播图与公告、宠物列表页（支持按品种、性别、年龄筛选）、宠物详情页（包含图片集、性格描述、健康状态）、救助上报入口、领养申请页、求助留言区。后台管理部分包括：宠物管理（新增、编辑、上下架、审核）、领养审核管理、救助工单管理、志愿者管理、公告管理、留言审核、数据统计面板。用户个人中心部分包括：注册登录、个人资料维护、我的领养申请（查看进度和审核意见）、我的救助上报（查看处理状态）、收藏宠物。

另外还建议加几个能够提升答辩亮点的“小而美”功能：比如站内消息通知，在领养申请状态变化时通过站内信提醒用户；比如宠物图片的多图上传和预览；比如首页展示领养成功数量和救助完成数量的统计卡片。这些功能代码量不大，但能让系统看起来完整、人性化。

3. 技术选型与项目骨架搭建：Spring Boot搭配什么前端方案更合适

选题定了，流程理清了，接下来遇到的问题就是技术栈。是选择前后端分离，还是用模板引擎做单体？这是一个非常关键的决策，直接决定你的开发方式和论文结构。

3.1 前后端分离与单体方案的对比

我个人的建议很明确：除非你只有两三个星期的时间，否则优先选前后端分离。原因有几点：

第一，前后端分离是目前企业开发的主流模式，答辩时讲出来更有说服力。第二，Vue 3配合Element Plus做后台管理界面，颜值高、组件全，宠物卡片和表单的展示效果远好于服务端渲染的模板页面。第三，分离架构下，你可以在论文中单独拿出一章写“前后端交互设计与接口规范”，这一章的内容非常充实。

当然，前后端分离也有代价：你需要同时维护两套工程，部署时也要处理跨域、代理等问题，学习曲线比单体方案略陡。但如果你的时间在四周以上，这些代价完全可控。

如果你是Java基础比较弱的同学，也可以选择Spring Boot + Thymeleaf的单体方案，把页面写在templates目录里。这种方案部署简单、逻辑集中，但答辩时技术亮点会比较有限。综合来看，我仍然推荐前后端分离，也就是后端Spring Boot提供JSON接口，前端由Vue项目调用。

3.2 后端核心依赖配置与工程结构

后端工程我建议用Spring Boot 2.7.18，搭配JDK 1.8或11。为什么不用Spring Boot 3.x？因为3.x对应JDK 17，很多学校的教学环境和老教程还停留在JDK 8，一旦出问题排查成本略高。2.7.x足够稳定，社区资料也最丰富。

pom.xml中核心依赖如下：

<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.5.2</version> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>8.0.33</version> </dependency> <dependency> <groupId>cn.hutool</groupId> <artifactId>hutool-all</artifactId> <version>5.8.15</version> </dependency> <dependency> <groupId>com.auth0</groupId> <artifactId>java-jwt</artifactId> <version>4.4.0</version> </dependency> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <optional>true</optional> </dependency>

其中Hutool工具包强烈推荐，它提供了日期处理、文件上传、验证码、Bean拷贝等常用工具，能帮你省下很多重复代码。JWT库用于实现无状态登录认证。MyBatis-Plus把单表CRUD的SQL几乎都封装好了，配合LambdaQueryWrapper写条件查询也很优雅。

工程结构上，我习惯按功能分包而不是按技术分包，也就是controller、service、mapper、entity这些层之下再按模块区分。对于这个系统，模块建议拆分成：auth（登录认证）、user（用户管理）、pet（宠物）、adoption（领养）、rescue（救助）、notice（公告）、message（站内消息）、statistics（统计）、common（通用配置和工具）。

3.3 前端工程与联调环境准备

前端使用Vue 3 + Vite + Element Plus + Axios。创建工程后，我建议先配置好两件事：一个是路由，另一个是Axios拦截器。路由结构参考：/login、/home、/pet/detail/:id、/adopt/apply/:petId、/user/profile、/user/adoptions、/admin/pet-manage、/admin/adoption-review、/admin/rescue-manage这些页面。Axios拦截器负责自动携带JWT，并在收到401时跳转到登录页。

联调阶段最容易出问题的是跨域。开发环境我推荐在Vite的vite.config.js里面配置代理，把/api开头的请求转发到Spring Boot的本地服务，这样可以避免每次请求都要处理CORS头。我常用的配置如下：

export default defineConfig({ plugins: [vue()], server: { port: 5173, proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } } })

后端只需要保证所有接口的路径统一以/api开头即可，部署上线时再通过Nginx做反向代理，同样可以避免跨域。这个方案我在多个项目里反复使用，稳定可靠。

4. 数据库设计：宠物档案、领养申请、救助工单三张核心表怎么做

数据库设计是这类系统的重中之重。表设计不好，后面写业务代码就会非常痛苦。我按照“先主后从”的思路，重点讲三张核心业务表，再补充几张支撑表。

4.1 用户表与宠物档案表的设计

用户表user字段包括：id（主键）、username、password（BCrypt加密存储）、nickname、phone、avatar、role（1普通用户/2志愿者/3管理员）、status（1启用/0禁用）、create_time、update_time。

宠物表pet字段包括：id、pet_name、category（猫/狗/其他）、breed、gender（1公/2母/0未知）、age_month（年龄按月存，便于前端展示“3个月/2岁”）、weight、vaccine_status（1已接种/0未接种）、sterilize_status（1已绝育/0未绝育）、health_desc、personality_desc、images（多张图片URL用逗号分隔，简单省事）、status（1待领养/2领养审核中/3已领养/4下架）、publisher_id（录入人）、create_time、update_time。

这里有一个设计小窍门：年龄不要用“出生日期”或者“年龄整数”，而是统一用月为单位。因为宠物幼年期的月龄变化很大，用字符串存“2个月”又无法做排序和筛选。技术上，前端展示时再做转换即可。

4.2 领养申请表与救助工单表的状态设计

领养申请表adoption_application字段包括：id、pet_id、user_id、real_name、phone、address、home_type（租房/自有）、has_yard（1有/0无）、has_other_pet、pet_experience、reason、status、review_comment（审核意见）、review_time、create_time、update_time。其中status是核心，我建议用整数类型，约定：1待审核、2初审通过待回访、3已完成、4已驳回、5已取消。

这里要注意，status要配合review_comment一起使用。驳回时管理员必须填写原因，用户在前台“我的申请”页面能看到具体意见，这样流程才完整。

救助上报表rescue_report字段包括：id、reporter_id（上报用户）、animal_type、location、description、image、status（1待审核/2已确认建单/3已驳回/4已完成）、create_time。

救助工单表rescue_order字段包括：id、report_id（关联上报）、assignee_id（指派志愿者）、status（1待接单/2处理中/3待回访/4已结案）、process_note、result_desc、feedback_images、finish_time、create_time、update_time。

4.3 冗余字段的设计权衡与关联查询优化

在做关联查询时，初学者最容易犯的错误是“一切靠外键关联，实时join”。比如查询领养申请列表时，每一行都要显示宠物名和申请人昵称。如果每次都去join三张表，数据量小还好，数据量大了会很吃力。

我的做法是适度冗余：在adoption_application中直接冗余pet_name和user_nickname这两个展示字段，在rescue_order中冗余report_description。这些字段在业务写入时一并保存，查询时直接取用。这样做的缺点是数据会冗余，但对于毕设这种体量的系统完全够用，换来的是查询接口简单直接、开发和调试效率高。论文里提到“空间换时间”的冗余设计思想，本身就是一个小加分项。

除了核心表，还需要补充：notice公告表、message站内消息表、favorite收藏表、dict字典表。其中dict表可以存宠物品种、救助类型等选项数据，前端下拉框的数据都从这里动态读取，避免把选项硬编码在前端。

5. 核心代码实现拆解：状态机审核、工单流转与权限校验

设计文档写好了，表也建好了，接下来才是真正写代码的阶段。这一部分我给你拆解几个关键环节的代码写法，并解释每一段代码背后的设计意图。

5.1 基于MyBatis-Plus的实体与通用封装

先看看宠物实体类的写法，用了Lombok简化getter/setter。这里注意images字段存的是逗号分隔的URL字符串，在返回给前端时会转换为字符串数组，我通常用JsonSerialize注解来处理：

@Data @TableName("pet") public class Pet { @TableId(type = IdType.ASSIGN_ID) private Long id; private String petName; private String category; private String breed; private Integer gender; private Integer ageMonth; private String images; @TableField(fill = FieldFill.INSERT) private LocalDateTime createTime; @TableField(fill = FieldFill.INSERT_UPDATE) private LocalDateTime updateTime; }

我使用IdType.ASSIGN_ID，让MyBatis-Plus自动生成雪花ID，避免在前端暴露连续的自增ID。雪花ID是Long类型，这里有一个经典的大坑，等会儿在第6节里专门说。

对应Controller写一个示例，展示项目中的编码风格：

@RestController @RequestMapping("/api/pet") public class PetController { @Resource private PetService petService; @GetMapping("/list") public Result getList(@RequestParam Integer category, @RequestParam String keyword) { LambdaQueryWrapper<Pet> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(category != null, Pet::getCategory, category) .like(StringUtils.hasText(keyword), Pet::getPetName, keyword) .eq(Pet::getStatus, 1) .orderByDesc(Pet::getCreateTime); return Result.success(petService.list(wrapper)); } }

总共不到二十行，前端即可拿到一个按条件筛选、按时间倒序的宠物列表。MyBatis-Plus的LambdaQueryWrapper在这种动态条件查询的场景下非常好用，条件为null时对应的拼接会自动忽略。

5.2 领养审核的Service实现：状态和权限双检查

领养审核是整个系统最核心的操作，处理起来必须小心。审核操作分两步：管理员通过、管理员驳回。驳回逻辑相对简单，直接改申请状态并填写意见。通过逻辑则要额外判断“宠物是否仍然处于待领养状态”，防止两个人同时提交申请导致冲突。

下面的代码包含了我比较推荐的写法：

@Transactional public boolean reviewAdoption(Long applicationId, Integer result, String comment) { AdoptionApplication app = applicationMapper.selectById(applicationId); if (app == null) { throw new ServiceException("申请记录不存在"); } if (app.getStatus() != 1) { throw new ServiceException("当前申请状态不可审核"); } Pet pet = petMapper.selectById(app.getPetId()); if (result == 2) { if (pet.getStatus() != 1) { throw new ServiceException("该宠物已被其他人申请或领养"); } app.setStatus(2); pet.setStatus(2); petMapper.updateById(pet); } else { app.setStatus(4); } app.setReviewComment(comment); app.setReviewTime(LocalDateTime.now()); applicationMapper.updateById(app); messageMapper.insert(app.getUserId(), "您的领养申请已" + (result == 2 ? "通过初审" : "被驳回"), comment); return true; }

这里有两个关键点。第一，@Transactional事务注解，确保“申请状态更新”和“宠物状态更新”要么都成功，要么都回滚，绝不出现申请通过了但宠物状态没变的脏数据。第二，审核前必须重新读取宠物状态并校验，这叫“并发状态检查”。不用悲观锁是因为毕设系统的并发量根本到不了那个程度，用乐观状态判断就够了。

类似的逻辑也用于救助工单流转。志愿者接单时，要判断工单是否处于“待接单”状态；提交处理结果时，要判断工单是否属于当前登录的志愿者。这些校验逻辑虽然简单，但写全了就能避免大量业务漏洞。

5.3 基于JWT的登录认证与角色权限控制

登录认证我使用的是JWT方案。用户登录成功后，后端生成一个token，包含用户ID和角色信息，并设置过期时间，前端将其存储在localStorage中。之后每次请求，Axios拦截器自动把token放到请求头里。

后端通过一个拦截器统一解析token：

@Component public class JwtInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { if (request.getMethod().equals("OPTIONS")) { return true; } String token = request.getHeader("Authorization"); if (token == null || !token.startsWith("Bearer ")) { throw new AuthException("未登录或登录已过期"); } Long userId = JwtUtil.parseToken(token.replace("Bearer ", "")); UserContext.set(userId); return true; } }

配合一个自定义注解@RequireRole，标注在需要特定角色访问的Controller方法上，比如管理员审核接口加@RequireRole("ADMIN")。在拦截器里读取当前用户角色后做校验，不通过则返回403。这套东西虽然比Spring Security轻量很多，但足够完成毕设的权限需求，而且你可以在论文里把认证授权的设计原理讲得很清楚。

6. 实战中的经典坑与排查思路：从Long精度丢失到跨域再到上传文件

技术实现讲得差不多了，现在来聊聊这个项目中最容易踩的几个坑。这些坑几乎每个做毕设的同学都会遇到，提前知道能省下好几天排查时间。

6.1 雪花ID传到前端丢精度的解决

如果你按我前面说的用了IdType.ASSIGN_ID生成雪花ID，就会遇到一个诡异的问题：列表请求成功后，前端拿到的id最后几位变成0，导致点击“查看详情”时传给后端一个错误的ID，接口返回空数据。

原因是JavaScript的Number类型只能安全表示2的53次方以内的整数，而雪花ID是19位的Long型，超出了安全范围。解决办法最简单的就是让后端在JSON序列化时把Long类型的ID转成字符串：

@JsonSerialize(using = ToStringSerializer.class) private Long id;

也可以在application.yml里配置全局规则，让所有Long类型都以字符串格式输出。这是非常典型的“开发环境一切正常、部署后功能异常”的坑，几乎每个前后端分离项目都会碰到。

6.2 前端接口联调时的跨域与代理问题

跨域的报错信息非常吓人，但本质就是浏览器同源策略的限制。我在第3节已经给出了Vite代理配置，这里再补充后端侧的处理。后端需要配置CORS允许的来源，建议放在一个WebMvcConfigurer里：

@Configuration public class CorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/api/**") .allowedOriginPatterns("*") .allowedMethods("GET", "POST", "PUT", "DELETE") .allowCredentials(true) .maxAge(3600); } }

联调环境如果端口不一致，主要用Vite代理解决；上线部署后，前端静态页面和后端接口在同一个域名下，跨域问题自然消失。所以如果前后端项目部署在一起，CORS这块基本不需要额外配置。

6.3 文件上传临时目录与图片回显问题

宠物图片上传是另一个高频踩坑点。我开发时用了一个很有意思的方式：把图片存本地磁盘的某目录（例如D:/upload/），数据库只存/api/file/xxx.jpg这样的路径。但当我把前端和后端分别放在两台机器上联调时，发现图片加载不出来。一排查，原来是前端通过代理访问/api/file/xxx.jpg，代理转发到后端后，后端的静态资源映射没有正确配置。

我的解决方案是注册资源映射：

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

还有另一个隐藏较深的坑：Spring Boot临时目录上传文件过多后会自动清理，导致上传的文件丢失。具体表现为，项目运行了一两天，之前上传的图片突然全变成404。解决办法是给后端配置一个稳定的外部目录存储文件，而不是依赖系统默认的临时目录。我在本地开发时一直用固定物理路径，就是为了避免这个问题。

7. 部署上线与文档准备的完整链路：从打jar包到答辩PPT

最后说说部署和文档。这是毕设的临门一脚，很多同学代码写得很溜，但不会打包部署、不会准备论文，最后非常吃亏。

7.1 前后端分离项目的打包与部署流程

后端打包非常简单，Maven执行package命令即可生成可执行的jar包。但我建议在打包前检查三件事：数据库连接配置是否指向正确的服务器地址、Redis地址和密码是否正确、配置文件是否开启了生产环境profile。我用了一套简单的多环境配置：

spring: profiles: active: prod --- spring: config: activate: on-profile: dev datasource: url: jdbc:mysql://localhost:3306/pet_adoption --- spring: config: activate: on-profile: prod datasource: url: jdbc:mysql://服务器地址:3306/pet_adoption

前端Vue项目打包时，要特别注意VITE_API_BASE_URL这个环境变量。开发时我们用代理转发，所以是相对路径/api；正式部署时如果Nginx配置了反向代理，依然可以用相对路径；如果前后端在不同服务器，则需要配置成完整的域名或IP地址。我的建议是尽量把前端静态页面和后端jar包放在同一台服务器，用Nginx统一处理静态资源和/api反向代理，省心很多。

7.2 毕业论文必备的核心章节与内容清单

毕业论文的结构大致是固定的，对于这种系统设计类题目，我建议包含以下章节：

第一章绪论部分，写研究背景和意义，重点写当前流浪动物问题的社会现状和传统线下领养方式的痛点（信息不透明、流程繁琐、缺乏监管），引出构建线上系统的必要性。国内外研究现状可以写一写目前市面上已有的领养平台，给个简单的对比分析，这块内容在论文查重阶段也相对安全。

第二章需求分析，把第2节梳理的角色和流程用文字和用例图表达出来，功能性需求和非功能性需求各写一列。非功能性需求一定要写：系统响应时间在2秒内、并发量支持100用户、数据每日备份等。这些量化指标能显著提升论文完整度。

第三章系统设计，内容包括：总体架构图、技术选型说明、数据库设计，其中数据库设计要包含ER图和各表字段说明，这是评委重点关注的部分。第四章是系统实现，按模块配界面截图加核心代码说明，注意截图要清晰，每张截图下面要有简要的文字解释。第五章是系统测试，列出测试用例表格（功能测试、接口测试、兼容性测试），测试用例要有具体的输入、预期结果和实际结果。

7.3 答辩前模拟的典型问题与回答思路

答辩时评委最常见的问题，不外乎这几类：

“你的系统安全措施有哪些？”——回答核心是三块：用户密码BCrypt加密存储、JWT无状态认证控制访问权限、后台接口对关键操作做了状态校验防止越权操作。除此之外还可以补充SQL注入防护（MyBatis-Plus的预编译机制天然防了注入）。

“为什么选择Spring Boot而不是其他框架？”——回答从生态、自动化配置、内置服务器、微服务友好四个角度展开。如果评委追问“你了解Spring Cloud微服务吗”，要大方承认单体架构对这个项目是合适的，微服务带来的分布式复杂度在这个场景下是过度设计。

“领养效率和系统性能怎么兼顾？”——回答可以提到数据库索引设计（在pet表的status、category上建索引，在adoption表的status上建索引）、Redis缓存热点数据、前端图片懒加载等。即使你实际没做Redis缓存，也可以说“在后续优化中考虑引入”，但要小心评委追问细节。

8. 项目做完之后的复盘：时间安排、扩展方向与我的实际体会

整个项目做下来，我最有感触的是：毕业设计的成败，关键不在代码写得多炫，而在于能不能把业务讲清楚、把流程做完整。

时间安排上，我建议拆成四个阶段：第一周做需求分析和数据库设计，把表和字段定下来；第二三周写后端接口，按模块逐个实现，每天完成一到两个Controller和对应的Service；第四周写前端页面，先把登录和后台框架搭起来，再逐页填充；第五周联调、修bug、打包部署；最后一周集中写论文和准备答辩PPT。如果时间充裕，第六周可以额外做一些优化，比如Redis缓存、数据统计的图表可视化，这些都是加分项。

这个项目后续的扩展方向也不少：比如可以引入Spring Security替代手写的JWT拦截器，增加OAuth2第三方登录；可以把救助工单对接高德地图API，实现救助地点的地图可视化；可以用WebSocket做站内消息的实时推送；甚至可以把系统拆分成微服务架构，配合Nacos和Feign做服务治理。这些方向都可以作为论文“未来展望”章节的素材。

最后说一个我个人的“私货”建议：提交前一定要做一次全流程回归测试。从注册、登录、发布宠物、提交领养、管理员审核、用户查看消息通知，到救助上报、建单、派单、志愿者处理、结案，完整走一遍，你会发现很多平时没注意的小问题，比如字段长度不够、状态显示中文不对、按钮权限没控制好等。把这些都修完再提交，系统的稳定性和答辩时的演示效果都会提升一个台阶。