希葛格的韩少君1. 项目整体设计与思路拆解
1.1 为什么选SpringBoot+SSM做宠物领养系统
先聊点实在的。宠物领养管理系统在毕业设计、课程设计里出现的频率一直很高，原因很简单：它的业务链条完整但不复杂，包含前台信息展示、用户注册登录、领养申请、后台审核、宠物管理、公告发布等模块，正好覆盖了JavaWeb开发的核心知识点。而SpringBoot+SSM这套组合，在当前的技术生态里属于“既能体现基本功、又贴近企业实际开发”的搭配，用来做这类系统非常合适。
很多人第一次接触SpringBoot+SSM会有点懵，觉得这两个东西是不是重复了。实际上它们不是竞争关系，SSM指的是Spring+SpringMVC+MyBatis这三件套，而SpringBoot是一个快速开发框架，它简化了Spring家族的配置方式。SpringBoot可以无缝整合SSM，本质上还是用Spring的IOC和AOP管理对象、用SpringMVC接收请求、用MyBatis操作数据库，只是不需要再写一堆繁琐的XML配置。
选这套组合做宠物领养系统，我个人的判断是三方面考量。第一，学习成本适中，网上关于SSM整合SpringBoot的资料非常多，遇到问题能很快查到解决方案。第二，代码结构清晰，Controller-Service-Mapper三层架构的分层方式很直观，写起来和答辩讲解时都有章可循。第三，技术栈不过时，SpringBoot现在依然是Java后端的主流框架，即便以后工作中用的不是这套组合，底层的Spring思想也是通用的。
还有一个现实问题就是时间。多数人做毕设或课程设计，时间都是挤出来的，不可能花几个月去研究微服务、分布式那套重型架构。SpringBoot让这个系统的落地变得很快，一个基础的宠物领养平台，从环境搭建到核心功能跑通，三到四周是完全可以做到的。
1.2 前台展示与后台管理的双端设计逻辑
宠物领养系统的核心矛盾在于“信息展示”和“权限控制”之间的平衡。面向普通用户的前台，需要的是便捷的信息浏览和申请流程；面向管理人员的后台，则需要一套完整的审核和管理机制。这两端必须共用同一套数据，但又要有清晰的权限边界。
我见过很多同学做这个选题的时候，把前后台揉在一起，用户登录之后既能看到管理入口也能操作后台功能，这是很不规范的做法。正确的思路是严格区分角色，普通用户注册登录后，只能在前台浏览宠物信息、提交领养申请、查看自己的申请进度；管理员则通过独立的后台入口登录，管理宠物信息、审核领养申请、发布公告和领养知识。两套界面互不交叉，同一套数据通过角色权限来控制可见性和可操作性。
从技术实现上，这就是SpringMVC拦截器加会话管理的事情。用户登录成功后把用户ID和角色存入Session，每次请求经过拦截器时判断访问的资源路径和角色是否匹配，不匹配就直接重定向到登录页。这样的设计在答辩的时候也很容易讲清楚，因为逻辑直接、代码不复杂，但又体现了对业务权限的理解。
宠物领养系统的业务流程还有个容易被忽视的点：状态流转。一只宠物从发布到被领养，要经历“待领养→收到申请→审核中→已被领养”这样的状态变化。如果你在数据库设计阶段没有把这个状态字段预留好，后面写领养申请功能时会非常痛苦。这个我在后面数据库设计的部分会详细展开。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 核心细节解析与实操要点
2.1 数据库表结构设计与状态管理
数据库设计是整个系统的地基。宠物领养系统核心表我一般建议至少包含这几张：用户表（user）、宠物表（pet）、领养申请表（adopt_apply）、公告表（notice）、领养知识表（knowledge），如果需要做分类筛选，还要有宠物分类表（category）或直接在pet表里用字段区分。
先看用户表，除了常规的用户名、密码、手机号、邮箱之外，一定要有一个role字段区分管理员和普通用户。有些人喜欢单独建一张角色表做用户-角色关联，但在这个体量的系统里，单角色字段就够了，一张关联表只会让代码写起来更啰嗦。密码存的是MD5加密后的密文，这个后面单独讲。
宠物表是整个系统的核心，字段设计直接决定了后续功能的扩展空间。宠物名称、品种、年龄、性别、健康状况、疫苗情况、绝育情况这些基本信息必须有，然后重点来了——status字段，这个字段标识宠物当前的状态，0表示待领养、1表示已被领养、2表示审核中（可能是管理员下架等状态）。还有一个字段容易被忽略：发布者或者来源，展示页需要显示这只宠物是救助站发布的还是个人发布的，这关系到领养流程的不同。
领养申请表是连接用户和宠物的桥梁，字段设计上要把申请信息做完整：申请人ID、宠物ID、申请时间、申请状态（待审核、已通过、已拒绝）、申请理由、居住情况、养宠经验等。为什么申请理由、居住情况这些看起来“不那么技术”的字段重要？因为后台管理员审核的时候，必须依据这些信息判断申请人是否适合领养。一个真实的领养系统，审核环节是最有人情味也最关键的环节。
做个简单的表关系说明：用户表与宠物表是一对多关系（一个用户可以发布/申请多只宠物，管理员也可以代发布），用户表与领养申请表是一对多，宠物表与领养申请表是一对多。用外键约束还是逻辑外键？我的建议是在代码里维护逻辑外键，不建物理外键约束。原因很简单——物理外键在删除数据时会带来很多麻烦，比如管理员想删除一条违规的领养申请记录，物理外键可能会阻断操作。逻辑外键就是存一个user_id、pet_id字段，关联查询的时候用JOIN或者MyBatis的关联映射，灵活很多。
2.2 前后台功能模块划分与核心功能清单
把功能模块理清楚，写代码的时候才不会东一榔头西一棒子。整个系统我按这样的逻辑来划分：
前台用户端要做的功能：用户注册与登录（含验证码）、宠物列表浏览（含分页和条件筛选）、宠物详情查看、领养申请提交与撤销、个人中心（修改资料、查看我的申请记录、修改密码）、公告与领养知识浏览。
后台管理端要做的功能：管理员登录、宠物信息管理（新增/编辑/上下架/删除）、领养申请审核（查看申请人条件、通过或拒绝申请）、用户管理（查看用户列表、禁用账号）、公告管理（发布、编辑、删除）、领养知识管理、数据统计（简单的仪表盘，比如待审核申请数、宠物总数、已领养数）。
每个功能模块听起来都不复杂，但真正动手写的时候会发现很多细节。举几个例子：宠物列表的分页筛选，前端要支持按品种、按年龄段、按状态来过滤，这种查询条件组合在Service层和Mapper层要写好动态SQL；领养申请提交时，前端要做表单校验（比如申请理由不能为空、手机号格式要合法），后端还要做二次校验防止绕过前端；后台审核领养申请通过以后，要自动联动修改宠物状态为“已被领养”，同时把其他的待审核申请自动拒绝——这个联动逻辑就是典型的业务规则落地，很多人没做这一步，导致一只宠物被多人领养的bug出现。
养宠物这件事，用户角度在乎的是“能不能方便地找到合适的宠物”，管理员角度在乎的是“如何确保每一只宠物都到了靠谱的人手里”。系统设计的每一个功能，本质上都是在为这两端的需求服务。把这句话理解了，答辩的时候随便问为什么做这个模块，都能答得上来。
2.3 登录鉴权与密码加密的工程实践
登录鉴权这块，我用的是非常经典但实用的方案：Session+拦截器。用户登录成功后，把用户对象放进Session，同时写一个LoginInterceptor实现HandlerInterceptor接口，在preHandle方法里从Session取用户，取不到就重定向到登录页。拦截器注册的时候需要注意，后台管理的所有请求路径要单独配置，普通用户的前台页面放行静态资源和公开页面。
具体来说，拦截路径的匹配规则是核心细节。后台管理路径比如/admin/**必须严格拦截，前台用户路径比如/user/**也要拦截（因为提交领养申请、查看个人中心都是需要登录才能做的），但首页、宠物列表、宠物详情这些公开页面要放行，否则游客什么都看不了，系统就失去了“展示”的意义。
密码加密这块，最基础的做法是MD5加盐。注意我说的是加盐，而不是直接MD5。直接MD5最大的问题在于彩虹表攻击，同样的密码加密结果一样，一旦数据库泄露，攻击者拿彩虹表一比对就能还原出密码。加盐的意思是在密码后面拼接一段随机字符串再加密，每个用户生成不同的盐值，存的时候把盐和加密后的密码一起存，校验时用同一个盐重新计算比对。代码写起来也不复杂：
java复制// 注册时生成随机盐值
String salt = UUID.randomUUID().toString().replace("-", "").substring(0, 6);
String encryptedPassword = DigestUtils.md5DigestAsHex((password + salt).getBytes());
// 登录校验时
String encryptedPassword = DigestUtils.md5DigestAsHex((rawPassword + user.getSalt()).getBytes());
if (user.getPassword().equals(encryptedPassword)) {
// 登录成功
}
用Spring自带的DigestUtils工具类就可以，不需要额外引入加密框架，对毕业设计来说完全够用。当然如果想让代码显得更专业一些，可以引入Spring Security或者Shiro，但说实话，在这个体量的系统里它们有些重了，而且配置复杂容易把自己绕晕，我建议用拦截器方案就好。
3. 实操过程与核心环节实现
3.1 从零搭建SpringBoot+SSM项目骨架
以一个真实的开发过程为例，从零开始搭这个项目，我按下面的顺序走。
第一步是创建项目。最常用的方式是到SpringInitializr官网或IDEA内置的初始化器里选SpringBoot版本（选2.x版本就行，稳定且网上资料最多），生成一个Maven项目，勾选Web、MyBatis、MySQL Driver这几个依赖。注意这里没有Security和Thymeleaf，Thymeleaf看你的前端方案，如果页面用JSP就加JSP相关的依赖，用Thymeleaf就加Thymeleaf依赖，用前后端分离的Vue就只加Web依赖然后单独搭建前端工程。
第二步是配置application.yml（或properties）。数据源信息、MyBatis的mapper扫描路径、驼峰命名映射配置、端口号、日志级别都在这里配置。这里有个很关键的配置项，MyBatis的驼峰映射必须要开启：
yaml复制mybatis:
configuration:
map-underscore-to-camel-case: true
mapper-locations: classpath:mapper/*.xml
如果不开启这个配置，数据库里的create_time字段映射不到Java实体类的createTime属性，查出来全是null。这是新手最容易踩的坑之一——数据明明在数据库里，但页面就是显示空白，查了半天发现是映射配置没开。
第三步是编写实体类和Mapper。实体类对应数据库表，字段用驼峰命名；Mapper接口定义操作方法，用@Mapper注解标记让Spring扫描到，对应的XML文件放在resources/mapper目录下。这一步看起来很机械，但写得规范与否影响后面所有业务逻辑的编写。
第四步是分层编写业务代码，Controller接收前端请求、Service处理业务逻辑、Mapper操作数据库。这里有一个经验：Service接口和实现类分开写，不要只写一个类直接用。为什么？答辩的时候老师可能会问你“Service接口和实现类为什么分离”，这是体现你说得清设计模式的好机会，而且实际操作中，当你给一个Service加事务注解的时候也会发现接口和实现分离更清晰。
3.2 SpringBoot与SSM整合的具体配置
SpringBoot整合SSM最大的好处就是不用写那些传统的Spring配置文件了，一切都用注解和配置类搞定。但有几个配置细节值得单独拎出来说。
事务管理。在SpringBoot中开启事务很简单，在启动类上加@EnableTransactionManagement注解，然后在需要事务的方法上标注@Transactional就行。宠物领养系统里典型的事务场景是用户注册——如果注册时既要插入用户基本信息，又要初始化用户的一些相关数据（比如领养积分或收藏表），其中任何一步失败，都要回滚，不能出现“账号创建了但关联数据没建”的中间状态。
还有一个场景就是领养申请审核通过时的事务：更新申请表状态为通过、更新宠物状态为已领养、拒绝其他所有待审核申请，这三步必须在一个事务里，任何一个失败都要全部回滚。
java复制@Transactional(rollbackFor = Exception.class)
public void approveApply(Integer applyId) {
// 1. 更新当前申请为通过
applyMapper.updateStatus(applyId, AdoptStatusEnum.APPROVED.getCode());
// 2. 更新宠物状态为已领养
petMapper.updateStatus(petId, PetStatusEnum.ADOPTED.getCode());
// 3. 拒绝其他待审核申请
applyMapper.rejectOtherPending(applyId, petId);
}
rollbackFor参数记着写上，默认情况下只对RuntimeException回滚，如果业务方法里抛了一个自定义的非运行时异常，事务是不会回滚的，数据就会出现不一致。这个细节很多人不注意，等发现数据乱了才回头排查。
3.3 宠物领养申请的核心业务逻辑实现
领养申请是整个系统的核心业务，它的完整流程是这样的：用户在前台看到一只“待领养”状态的宠物，点击“申请领养”，进入一个表单页面填写个人信息和申请理由，提交后生成一条待审核的申请记录，同时前端页面上的宠物状态变为“审核中”（或者维持待领养状态但按钮变为“已申请”防止重复提交）。管理员在后台看到这条申请记录，查看申请人的详细资料，决定通过或拒绝。
这里有一个容易出现的业务漏洞：重复申请。如果用户点击了多次提交按钮，系统会生成多条待审核申请记录，这不仅让管理员混乱，还可能导致一只宠物被多次审核通过。解决方案有两种——前端在提交成功后禁用按钮（防小白用户），后端在插入前校验该用户是否已对该宠物提过申请（防恶意用户）。两种都做才安全。
再看User表里需要扩展的一个字段——申请人资质相关的基本是做审核依据的。很多同学做毕业设计时只做了一个“备注”字段让用户填理由，这样太简单了。我在设计领养申请表单时，把“申请理由”、“居住情况”、“养宠经验”、“接收领养回访”这几个字段都做上，前两个必填，后两个用户自愿填写。为什么要这样做？因为管理员审核时这些信息是判断依据，也贴合实际的宠物领养场景中救助站对领养人的考察逻辑。
来看关键代码，领养申请提交的Service方法大致这样：
java复制public Result submitApply(AdoptApplyVO applyVO, Integer userId) {
// 1. 校验宠物状态是否为待领养
Pet pet = petMapper.selectById(applyVO.getPetId());
if (pet == null || !PetStatusEnum.PENDING.getCode().equals(pet.getStatus())) {
return Result.error("该宠物暂不可领养");
}
// 2. 校验是否重复申请
int count = applyMapper.countByUserAndPet(userId, applyVO.getPetId());
if (count > 0) {
return Result.error("您已经申请过该宠物，请勿重复提交");
}
// 3. 插入申请记录
AdoptApply apply = new AdoptApply();
apply.setUserId(userId);
apply.setPetId(applyVO.getPetId());
apply.setReason(applyVO.getReason());
apply.setStatus(AdoptStatusEnum.PENDING.getCode());
applyMapper.insert(apply);
// 4. 更新宠物状态为审核中
petMapper.updateStatus(applyVO.getPetId(), PetStatusEnum.REVIEWING.getCode());
return Result.success("申请提交成功");
}
这个流程里明确了状态流转如何与申请动作联动，每一步都有明确的业务意义。写代码的时候把每一步的职责想清楚，业务就不会乱。
3.4 宠物信息管理模块的完整实现
宠物信息管理是后台管理端使用最频繁的功能。管理员的日常工作就是录入新到的宠物、更新宠物的健康信息、下架已经领养走的宠物、编辑领养公告等。
宠物信息的上传涉及图片处理。前台展示页面需要宠物图片，我在实现时使用了本地上传方式：配置一个静态资源映射，把项目外的某个磁盘目录映射成HTTP访问路径，上传的图片存到这个目录，数据库里存相对路径。这样做的原因是不需要引入OSS之类的云存储服务，在毕业设计中本地上传已经够用。
yaml复制# application.yml 静态资源映射配置
spring:
web:
resources:
static-locations: file:${upload.path}/
upload:
path: /data/pet-images/
再写一个文件上传的Controller方法，把MultipartFile保存到指定目录，文件名用UUID重命名避免中文名和重复名带来的问题。图片上传还有两个细节：一是要校验文件类型和大小，只允许jpg、png、webp等图片格式且不超过2MB；二是要进行图片压缩或至少约束上传尺寸，不然用户上传一张5MB的高清照片，前端页面加载会非常慢。
宠物信息编辑的时候，要注意区分图片的处理策略——是重新上传替换了旧图，还是保留了原来的图片路径。这个逻辑不处理好的话，会出现后台明明改了图片，前台还是显示旧图的情况。我用的办法是：如果上传了新图片就更新图片路径同时删除服务器上的旧图片文件；如果没有上传新图片就保留原有图片路径不动。
3.5 后台审核与数据管理的实现要点
后台管理端的代码骨架和前台的逻辑有很多相似之处，但访问控制和功能定位完全不同。我在实际操作中会把后台管理的请求路径统一以/admin开头，然后用一个AdminInterceptor单独拦截。后台管理员的账号由系统初始化数据插入，不是通过前台注册接口产生的，这一点要在设计说明和答辩时讲清楚。
审核功能的实现逻辑其实很清晰：管理员打开申请列表，看到所有待审核的记录，点击某一条记录进入详情页，详情页展示申请人信息、申请理由和宠物信息，管理员可以通过，也可以拒绝并填写拒绝原因。拒绝原因要回传给前台用户，让用户知道为什么自己的申请被拒。
数据管理方面，用户列表要支持按用户名或手机号模糊查询，宠物列表要支持按状态和品种筛选。这里用到的核心技术是MyBatis的动态SQL，if标签判断条件不是空就拼接查询条件：
xml复制<select id="selectPetList" resultType="com.example.entity.Pet">
select * from pet
<where>
<if test="status != null">
and status = #{status}
</if>
<if test="category != null and category != ''">
and category = #{category}
</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>
这样的写法可读性和维护性都很好，答辩的时候老师问“多条件组合查询怎么做”，直接就可以拿这段代码来讲解。动态SQL是MyBatis最实用的特性之一，也是面试和答辩喜欢问的知识点，这个模块做好了对后期的讲解很有帮助。
3.6 公告与领养知识模块的轻量设计
公告和领养知识这两个模块属于内容型功能，技术上比较轻量，但业务上不能少。领养知识模块的意义在于，它让整个系统不只是“领养登记处”，而是一个有引导性的平台——用户看到领养条件和注意事项，会更有责任心地对待领养这件事。
实现上其实就是简单的CRUD。前台页面展示公告列表和知识列表，详情页展示具体内容；后台管理员可以发布、编辑、删除。注意标题和摘要的设计，列表页需要显示标题、发布时间、浏览量，详情页展示完整内容。浏览量要+1，这个统计可以让平台运营者知道哪些内容用户更关注，为内容运营提供依据。
内容字段用TEXT类型存储，如果是富文本内容，要注意XSS防御。后台提交的内容在前台展示时，要对HTML标签做过滤或转义，避免存储型XSS。用SpringBoot自带的HtmlUtils.htmlEscape就能做基础转义，如果想让排版效果好一些，可以使用富文本编辑器配合白名单过滤，但这就复杂一些了。毕业设计阶段做好基础转义，然后在答辩时能说出“防止XSS攻击”这个点就够了。
4. 常见问题与排查技巧实录
4.1 类找不到、依赖冲突与环境问题
这一类问题的出现频率最高。Maven项目导入依赖的时候，SpringBoot版本和MyBatis相关依赖的版本匹配不上，会出现一堆让人摸不着头脑的报错。我踩过的一个典型坑是：用了SpringBoot 3.x版本，但MyBatis Starter用的还是适配2.x的老版本，导致启动时直接报错。
解决办法很简单：不要盲目追新版本。用SpringBoot 2.5.x到2.7.x这个区间内的版本，搭配mybatis-spring-boot-starter 2.x对应版本，是经过大量项目验证的稳定组合。版本选型的关键在于兼容性而非最新，很多人忽略这一点，生产环境也一样——稳定永远第一位。
IDEA里常见的坑还有：Maven仓库配置不对，依赖下载不下来；JDK版本和SpringBoot要求的不匹配（SpringBoot 2.x要求Java 8或11，用了17在某些版本也会出问题）；Lombok插件没装导致实体类报错。这些都是环境层面的问题，建议把本地的Maven仓库地址和IDEA的Java编译器版本一起检查一遍再开始写代码。
4.2 会话失效、登录状态丢失与页面跳转错误
前后台分离实现的时候，经常出现的问题包括：登录成功的用户刷新页面后会话丢失、访问后台管理页面反而跳到前台登录页、用户登录之后还能直接通过URL访问后台接口。这些表面上是“跳转不对”的问题，根源都在拦截器和会话管理上。
拦截器注册的细节尤其要注意。SpringBoot中自定义拦截器要注册到WebMvcConfigurer的addInterceptors方法里，并且用addPathPatterns指定拦截路径，excludePathPatterns放行静态资源。静态资源没放行会导致页面加载不出CSS和JS，页面样式全乱了。
会话丢失的问题一般出在Session配置上，最常见的原因是把用户信息放进了request而不是session，或者用了重定向（redirect）导致请求对象被重置。登录信息一定要放session，而且建议封装一个LoginUser对象（包含userId、username、role），而不是放一堆散字段，这样取用方便代码也干净。
另外一个常见的登录逻辑问题：用户登录成功后，页面显示的是登录之前的缓存数据。这个问题通常是因为页面用了浏览器缓存，刷新一下就好了，但要在代码上根治，可以在Controller返回视图时设置禁止缓存的响应头，或者跳转时加时间戳参数。
4.3 数据库查询结果与页面显示不一致
“数据库里有数据，页面死活不显示”这个问题的排查路径通常是：看SQL是否执行成功、看查询结果是否返回、看后端返回给前端的数据结构、看前端JS的赋值逻辑。一步步缩小范围，切忌瞎猜。
最常见的原因是实体类字段与数据库表字段的映射不一致。如果开启了map-underscore-to-camel-case还是查不出来，就检查实体类的驼峰命名是否和数据库下划线命名对应上，比如数据库字段是create_time，实体类必须是createTime，一个字都不能差。还有类型问题，数据库的tinyint和Java的Integer/Boolen之间的映射，MyBatis默认有它的规则，但如果你把status字段定义成了Integer却试图在代码里直接当布尔值用，就会出意外。
另一个容易被忽略的原因——SQL查出来了但返回给前端的数据结构中多包了一层。比如本来应该返回List
4.4 前端常见问题排查
前端问题里最让人头疼的是图片不显示。很多同学的图片路径写的绝对路径，例如/img/pet/xxx.jpg，但上传目录实际不在项目resources里，而是在本地磁盘某路径，就导致404。绝对路径还有一个更严重的问题：项目部署到服务器后，路径完全对不上，所有图片都废了。正确做法是用相对路径存储，通过配置静态资源映射来访问。
关于相对路径和映射问题，这属于做了之后才能理解为什么的典型情况。我建议在数据库里存储的图片路径用“/images/2025/01/xxx.jpg”这种相对地址，访问时由静态资源映射自动指向真实磁盘位置。部署的时候只需要修改配置文件里的upload.path，不需要改数据库里的任何路径。
乱码问题也是高频问题。页面中文显示问号，通常是编码问题，检查三个地方：数据库连接URL有没有加characterEncoding=utf8、页面模板有没有声明UTF-8、IDEA的文件编码有没有设置为UTF-8。还有前端传到后端的数据中文乱码，需要在SpringBoot里配置HTTP编码过滤器，其实SpringBoot默认已经配置了UTF-8编码，所以通常还是数据连接URL的问题。
4.5 部署过程中的常见问题
项目写好了要打包部署，SpringBoot项目打包成Jar文件后在服务器上运行，有同学会遇到“本地可以运行，服务器上跑不起来”的问题。除了前面说的图片路径问题之外，还有几个高频坑。
数据库连接问题。服务器上的MySQL版本和本地不一致，或者密码、权限配置有问题，或者没有把数据库的SQL脚本在服务器上导入，都会导致连接失败。这个可以直接用MySQL客户端连上去测一下，再用telnet测3306端口通不通，逐层排查。如果用的云服务器，记得在安全组规则里放行3306端口。
Jar包运行的内存问题。服务器的内存如果比较小，直接java -jar启动可能会因为内存不足而OOM。加JVM参数限制内存即可：
bash复制java -jar -Xms256m -Xmx512m pet-adopt-system.jar
还有日志问题。部署到服务器后，没有控制台可以直接看输出，如果程序启动失败，需要查看日志文件。SpringBoot默认没有配置输出到文件的日志，建议引入logging配置把日志输出到指定目录，这样排查部署问题会方便很多。
5. 答辩讲解与项目总结实战经验
5.1 答辩前需要准备的核心问题清单
如果你的项目是用来答辩的，代码写完只是完成了40%，剩下60%在于你怎么把项目讲清楚。答辩老师看重的不是你的界面多漂亮，而是你是否真正理解自己写的代码。我给自己准备了一份问题清单，每次都按这个方向去准备。
第一个方向是为什么选型。为什么用SpringBoot而不用传统的SSM（Spring原始配置方式）？答案的核心是SpringBoot简化了配置、内嵌了Tomcat服务器、提供了丰富的Starter依赖，让开发者能更专注于业务逻辑而非配置过程。但要注意，SpringBoot底层依然是Spring的IOC和AOP机制，这个基础一定要理解、能讲清楚。
第二个方向是业务闭环。领养申请的完整流程是什么？从用户提交申请、系统校验、生成记录、管理员审核、更新状态到最终前端页面的反馈变化，每个环节对应的代码在哪里实现？如果老师问“一只宠物被申请了100次，会怎样”，你能不能答上来数据库里会有100条申请记录、每只宠物只会有一条记录被通过、其余被自动或手动拒绝。
第三个方向是安全性。密码是怎么存的？为什么用MD5加盐？有没有考虑SQL注入？这些问题的背后体现的是你有没有安全意识。能说出MyBatis预编译机制防SQL注入、参数校验、XSS转义，比说了很多大而空的架构概念有用得多。
5.2 以实战为基础的复盘与经验沉淀
回头看整个项目，最核心的一条经验是：写业务系统，先理清业务再写代码。宠物领养系统看起来是一个简单的毕业设计选题，但真正把它做完整、做规范、能讲清楚，涉及的知识点一点也不少——数据库设计、接口规划、事务控制、权限管理、文件上传、前后端联调、部署运维，每个环节都有实际的坑要踩。
开发过程中养成好的代码习惯也很重要。写实体类时把字段对齐、写SQL时把缩进排好、给核心方法写注释说明业务逻辑，这些习惯在答辩、后续找工作时都是加分项，因为面试官看简历中的项目时，会通过代码风格判断你的工程素养。
最后说一个小点：宠物领养系统做完之后，如果想扩展，方向非常多。比如增加一个宠物丢失查找模块，或者做一个库存/捐助功能，或者给用户增加收藏功能、给管理员增加数据可视化图表，都能让项目变得更加完整。项目的价值在于它能生长，而不是做完就封存。
我个人的看法是，这个选题虽然看起来“简单”，但它确实是一个恰到好处的综合训练载体。对想做毕业设计的同学来说，它能让你完整走一遍Web开发的流程，同时避开复杂架构给你带来的挫败感。认真做完、吃透每一行代码，这个项目能带给你的收获，会比“毕业设计通过”本身要多得多。