企业官网建设流程全解析

系统确实能做，而且做出来后你会发现，技术本身没什么门槛，真正花时间的是业务流程的设计——比如一只宠物从发布到被领养，中间要经过几个状态，谁来申请、谁审批、审批不通过怎么办，这些想清楚了，代码反而是水到渠成的事。

这篇文章我就按自己实际开发的经验来拆一拆这个系统：从选题价值、技术组合、数据库设计，到核心代码怎么组织、SpringBoot整合SSM的坑怎么避、最后部署上线和面试答辩怎么讲，一条线讲透。不管你是正在为毕设发愁的学生，还是想拿个完整项目练手的Java学习者，照着这个思路走，都能少走很多弯路。

1. 先聊点实际的：这系统到底解决什么问题

1.1 线下宠物领养的真实痛点

宠物领养这件事，在线下其实是一堆信息孤岛。救助站、个人送养人、想领养的人，各方信息散落在微信群、朋友圈、甚至一张张纸质登记表里。送养人不知道谁是真的想养，领养人不知道哪里有猫可领，救助站每天接到大量询问电话，来回沟通成本极高。

更麻烦的是审核环节。你没法知道申请领养的人是否靠谱，领养之后宠物过得怎么样，有没有被转卖、弃养。很多救助组织其实有回访制度，但全靠人工电话和微信联系，时间一长就断了。

我见过一个做救助的朋友，手机通讯录里存了几百个领养人的名字，靠备注“花花-已领养-3月回访”来管理，看着都累。所以，一个能集中展示宠物信息、把领养申请和审核流程搬到线上、并且记录每只宠物去向的管理系统，几乎是刚需。

1.2 这个系统的业务本质是什么

如果你把需求翻译成技术语言，会发现这个项目的核心其实是一套标准的管理信息系统（MIS）——

• 普通用户：注册、登录、浏览宠物列表、查看宠物详情、提交领养申请、查看申请进度。
• 管理员：登录后台、发布宠物信息、审核领养申请、管理用户、发布公告。
• 系统级功能：宠物图片上传、领养申请状态流转、分类搜索、分页展示。

用生活化一点的话说，这就像一个小型“中介平台”：宠物是房源，领养人是租客，管理员是中介。房源要上架，租客要提交资料，中介要审核把关，成交之后房源状态从“待出租”变成“已租出”。想清楚这个模型，整个系统的模块划分就非常清晰了。

1.3 为什么这个选题在毕业设计里长盛不衰

每年到了毕设选题季，宠物领养管理系统都是热门。原因很简单：业务链条完整，但复杂度适中。

它既有基本的增删改查（用户、宠物、公告），又有带状态流转的业务逻辑（领养申请审核），还有文件上传（宠物图片）、权限控制（管理员和普通用户）、搜索分页这些高频考点，做完之后能讲的技术点非常多。而且选题本身带公益属性，答辩时导师问“你这个项目有什么意义”，答案现成的，不用担心无话可说。

最关键的是，这套系统的工作量对于一个人来说刚好——不靠团队协作也能独立完成，代码量不大，但五脏俱全，特别适合用来检验自己对SpringBoot和SSM的掌握程度。

2. SpringBoot和SSM那点事：为什么这么组合不别扭

2.1 先搞清楚概念上的误解

很多新手看到“Java+SpringBoot+SSM”这种标题就懵了：SpringBoot和SSM不是两套东西吗，怎么放在一起？

说真的，这个误解太常见了。听我一句话理解：

SSM = Spring + SpringMVC + MyBatis，是三个框架的组合，负责解决“对象管理、Web请求处理、数据库操作”三类问题。

SpringBoot = Spring家族推出的快速开发脚手架，本质上是把Spring、SpringMVC这些底层框架包了一层，通过自动配置和起步依赖，让你不用写一堆XML配置就能跑起来。

所以“SpringBoot整合SSM”的意思是：用SpringBoot作为项目骨架，底层仍然使用SpringMVC处理请求、MyBatis操作数据库。SpringBoot没有替代SSM，只是把Spring和SpringMVC的配置过程大幅简化了。你可以理解为SSM是一套精装修的施工方案，而SpringBoot是“拎包入住”的成品房，但水电管线那套底层工艺还是同一个师傅做的。

2.2 为什么毕设项目和实际小项目都推荐这套组合

我自己的评价是：这套组合是当前Java Web项目里“性价比”最高的搭配，尤其适合一个人开发的中小型系统。

• 求职面试有话题：Java岗位面试必问SSM和SpringBoot，做完这个项目等于把高频考点全部实战了一遍。
• 参考资料最全：从上世纪风格的XML配置教程到最新的SpringBoot 2.x案例，搜“SpringBoot+MyBatis”能搜出一整片海洋，踩坑时永远能找到前人经验。
• 开发效率足够：SpringBoot的自动配置把繁琐的Bean声明全干了，你只需要专注业务代码。MyBatis的SQL可控性强，复杂的关联查询、状态更新自己写SQL反而更直接。

当然要承认，如果是大型互联网项目，SpringBoot+MyBatis不是唯一选择，Spring Cloud全家桶、MyBatis-Plus、JPA都有各自生态位。但在“一个人从零到上线跑通一个管理系统”这个场景下，SSM组合就是最顺手的那把刀。

2.3 版本搭配建议（血泪教训）

版本问题我一个一个踩过，这里直接给你一套稳妥的搭配方案，照着配基本不会翻车：

这里特别要提醒一句：不要一上来就上SpringBoot 3.x。SpringBoot 3要求JDK 17起步，而且把javax包名换成了jakarta，很多网上教程的代码直接跑不起来，对于想快速完成毕设或课设的同学来说纯属给自己挖坑。如果没有特殊要求，SpringBoot 2.7全家桶就是最稳妥的选择。

2.4 前后端方案怎么选：模板渲染还是前后端分离

这是一个很容易纠结的问题。我的建议非常明确：如果任务是“独立完成一个管理系统”，首选Thymeleaf模板渲染，不推荐强行上Vue前后端分离。

原因有两个。第一，模板渲染模式下后端同学不用处理跨域问题，CORS、预请求、Token鉴权这些额外的复杂度全部绕开了；第二，页面直接由Controller渲染返回，调试的思路更线性，出问题容易排查。前后端分离的优势是在多人协作、大型团队时才能体现出来，单人开发纯属增加工作量。

当然，如果你对Vue已经熟练掌握，做前后端分离也完全可以，只要记得在后端处理好跨域配置和登录状态传递。这篇主要以Thymeleaf方案为主线来讲，因为对大多数人来说这是最快跑通的一条路。

3. 模块和数据库：动工之前先想清楚的几件事

3.1 角色权限：这套系统的使用者只有两类人

权限模型没必要搞RBAC那种复杂设计，这套系统里两类角色就够用：

• 管理员（role=0）：除了不能用普通用户的领养功能，其他都能干——发布宠物、审核申请、管理用户和公告。
• 普通用户（role=1）：浏览宠物、查看详情、提交领养申请、查看自己的申请进度、修改个人信息。

权限控制的做法很简单：登录时把用户对象放进Session，拦截器里取Session判断是否登录，到管理员接口时再校验一次role字段。后面第5章我会给出具体实现代码。

3.2 核心业务流程：一只宠物从发布到被领养要经过哪些状态

画清楚业务流转，比写代码重要得多。这套系统的核心链路是：

管理员发布宠物（状态：待领养） ↓ 用户在列表看到宠物，点击提交领养申请（申请状态：待审核） ↓ 管理员审核申请（通过 / 拒绝，拒绝需填写备注） ↓ 通过 → 宠物状态更新为“已领养” 拒绝 → 用户看到拒绝原因，宠物继续待领养

这里有一个非常关键的细节：宠物状态和申请状态是两个独立的状态字段，不能混在一起。宠物状态只关心“是否还在等待领养”，申请状态关心的是“这条申请走到哪一步了”。很多新手在这里会犯迷糊，把两个状态搞成一个字段，结果一只宠物被多人申请后，状态直接乱套。

3.3 数据库表设计：四张核心表加两张辅助表

我建议的表结构是这样的：

user 用户表

pet 宠物表

adoption_apply 领养申请表

notice 公告表：id、title、content、create_time，管理员发布站内公告用。

comment 留言表：id、pet_id、user_id、content、create_time，用户可以留言咨询宠物情况。

几个设计上的小心得：

• 状态字段用tinyint数字，不要用字符串。一方面查询效率高，另一方面扩展方便，以后状态增加到3、4，数字编码比字符串更灵活。
• 表与表之间用逻辑关联，不用物理外键。毕设项目经常需要演示删除功能，物理外键会在删除关联数据时各种报错，逻辑外键靠代码控制完全够用，而且后期改起来轻松。
• 所有时间字段都用datetime，千万不要图省事存字符串。后面按时间排序、统计时你会感谢当初的决定。
• 密码一定不能明文存，用BCrypt加盐哈希，MD5那种方案现在基本等于裸奔。

4. 核心实现思路：从登录到领养审核这条路怎么走通

4.1 登录鉴权：用Session加拦截器，简单还能讲清楚

登录方案我推荐老牌的Session方案，别一上来就搞JWT。为什么？因为这套系统是模板渲染，没有前后端分离的需求，Session天然适配，而且拦截器判断起来非常直观。

先写一个登录拦截器：

public class LoginInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { HttpSession session = request.getSession(); User user = (User) session.getAttribute("loginUser"); if (user == null) { response.sendRedirect("/login"); return false; } return true; } }

再写一个管理员拦截器，继承登录拦截器的逻辑，额外校验role：

public class AdminInterceptor extends LoginInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { boolean loggedIn = super.preHandle(request, response, handler); if (!loggedIn) { return false; } User user = (User) request.getSession().getAttribute("loginUser"); if (user.getRole() != 0) { response.sendRedirect("/index"); return false; } return true; } }

在WebConfig里注册拦截器，这一步非常容易踩坑的是放行路径。登录接口、注册接口、静态资源（CSS、JS、图片）都必须放行，否则页面会一片空白：

@Configuration public class WebConfig implements WebMvcConfigurer { @Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(new LoginInterceptor()) .addPathPatterns("/**") .excludePathPatterns("/login", "/register", "/index", "/static/**", "/images/**", "/pet/list", "/pet/detail/**"); registry.addInterceptor(new AdminInterceptor()) .addPathPatterns("/admin/**"); } }

4.2 宠物发布与图片上传：路径存储的坑一次说清

宠物发布是管理员的核心操作，表单里除了文本信息，还有一张图片。SpringBoot处理文件上传非常简单，用MultipartFile接收即可，但有一个点非常容易踩坑——数据库里存什么路径，页面上怎么回显。

我的做法：图片保存到项目的src/main/resources/static/images/uploads/目录（本地调试时直接用绝对路径保存），数据库只存相对路径如/images/uploads/xxx.jpg。页面直接用<img th:src="${pet.image}">就能访问，因为SpringBoot默认把static目录映射到根路径，/images/uploads/xxx.jpg自动对应到静态目录里的文件。

文件上传的配置写在application.yml里，默认限制只有1MB，上传大图会直接报错：

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

如果你部署到云服务器，图片保存到绝对路径是更好的方案，比如/data/pet-images/，然后通过一个虚拟路径映射到静态资源。本地毕设的话用static目录最省事，打包成jar时图片也会一并打进去。

4.3 领养申请的状态流转：并发场景下的核心代码

这是整个系统里最值得讲的一段代码，也是面试时最能体现水平的点。

先看提交申请的Service逻辑：

@Service public class AdoptionApplyService { @Autowired private PetMapper petMapper; @Autowired private AdoptionApplyMapper applyMapper; @Transactional public void submitApply(Integer petId, Integer userId, String reason) { Pet pet = petMapper.findById(petId); if (pet == null || pet.getStatus() != 0) { throw new RuntimeException("该宠物暂不可领养"); } AdoptionApply apply = new AdoptionApply(); apply.setPetId(petId); apply.setUserId(userId); apply.setReason(reason); apply.setStatus(0); // 待审核 apply.setApplyTime(new Date()); applyMapper.insert(apply); } }

这里有三层思考：

• 校验合法性：宠物必须存在且状态是待领养，不能对已领养的宠物提交申请。
• 事务保护：加@Transactional，确保校验和插入操作要么全部成功、要么全部回滚。
• 为什么不在这里直接改宠物状态：因为申请需要管理员审核，提交申请不等于领养成功，宠物状态必须在审核通过时才变更。

再看审核通过的方法，这里有个并发问题很多人会忽视：

@Transactional public void approveApply(Integer applyId) { AdoptionApply apply = applyMapper.findById(applyId); if (apply == null || apply.getStatus() != 0) { throw new RuntimeException("申请状态异常"); } // 关键：这条update语句自带条件判断，防止并发下两只猫被同一只宠物申请成功 // 场景：管理员同时点了两个不同申请者的“通过”按钮 int rows = petMapper.updateStatusIfAvailable(apply.getPetId(), 1); if (rows == 0) { throw new RuntimeException("该宠物已被其他申请领养"); } apply.setStatus(1); apply.setAuditTime(new Date()); applyMapper.updateStatus(apply); }

对应的Mapper SQL：

<update id="updateStatusIfAvailable"> UPDATE pet SET status = #{status} WHERE id = #{petId} AND status = 0 </update>

这里的核心逻辑是：通过UPDATE ... WHERE status = 0影响行数来判断是否更新成功。如果两条审核请求同时到达，数据库行锁会保证只有一个请求更新成功，另一个影响行数为0，直接抛异常。这个方案比先查再改靠谱得多，也是“乐观锁”思想的一种落地实践。

4.4 搜索、分页和分类展示

宠物列表页支持按分类筛选、按关键字搜索、分页展示。分类筛选直接用MyBatis的动态SQL判断条件，搜索用LIKE CONCAT('%', #{keyword}, '%')拼接关键字，注意不要直接拼字符串进SQL，防SQL注入的习惯要养成。

分页我用的是MyBatis官方分页插件PageHelper，配置很简单：

PageHelper.startPage(pageNum, pageSize); List<Pet> petList = petMapper.selectPetList(category, keyword); PageInfo<Pet> pageInfo = new PageInfo<>(petList);

PageHelper的底层原理是拦截器自动拦截要执行的SQL，在语句后面拼接LIMIT，核心的点在于：PageHelper.startPage()之后的第一条SQL会被分页，所以必须紧跟在查询语句前调用，中间不要插入其他数据库操作。这个坑我见很多人踩过——startPage之后先执行了别的Mapper查询，分页结果全乱了。

5. 我把源码调通的完整过程：这些坑你大概率也会踩

这一章把我实际调试过程中遇到的高频问题按排查链路整理出来。每个问题我都按“现象 → 排查思路 → 根因与解决”的顺序讲，而不是直接告诉你答案，这样下次遇到问题时你能自己定位。

5.1 启动报错：找不到MyBatis的Mapper

现象：项目一启动就报Invalid bound statement (not found): com.xx.mapper.UserMapper.selectByUsername。

排查链路：我先打开启动类看有没有加@MapperScan，确认加上了；然后去application.yml看mybatis.mapper-locations配置；最后发现问题是Mapper XML文件路径写错，我放在resources/mapper目录，配置里写的却是classpath:mybatis/*.xml。

根因与解决：SpringBoot整合MyBatis时有两个地方必须对应——启动类加了@MapperScan("com.example.petadoption.mapper")，同时配置文件指定XML位置：

mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.example.petadoption.entity configuration: map-underscore-to-camel-case: true

这里顺手说一下map-underscore-to-camel-case这个配置，它能把数据库的create_time自动映射到实体类的createTime，省掉大量resultMap手写工作。推荐打开，除非你的字段命名风格不一致。

5.2 页面样式全丢了：拦截器把静态资源拦了

现象：登录页能打开，但是没有任何CSS样式，页面惨不忍睹。

排查链路：按F12看Network，发现CSS请求全被重定向到/login了。进一步检查，所有静态资源请求都返回302，那我基本确定是登录拦截器把静态资源也拦截了。

根因与解决：拦截器配置的放行路径没有包含静态资源。SpringBoot 2.x中静态资源默认路径是/static/、/public/、/resources/、/META-INF/resources/，拦截器不会自动放行，必须在excludePathPatterns里手动排除：

.excludePathPatterns("/static/**", "/css/**", "/js/**", "/images/**", "/error")

这个坑在模板渲染方案里非常高频，几乎每次写新拦截器都会碰到一次。记住一点：拦截器放行路径是所有Web项目的“天生敏感区”，写完先检查静态资源有没有被排除。

5.3 图片上传报错：超出大小限制

现象：上传宠物图片时控制台报FileSizeLimitExceededException或前端提示Maximum upload size exceeded。

排查链路：我先看报错信息，明确是MaxUploadSizeExceededException，说明是配置问题而不是代码逻辑问题。去查SpringBoot默认的multipart配置，发现默认单文件上限是1MB。管理员随便拍一张宠物照片就能超过这个数。

根因与解决：在application.yml里调大上传限制，配置我上面给出过，这里再强调一遍max-file-size和max-request-size的区别——前者是单个文件上限，后者是单次请求所有文件的总上限。如果只配了前者，一次上传多张图还是会踩后者的限制。

5.4 数据库查询时间差了8小时

现象：页面上显示的发布时间比数据库里的实际时间早8个小时。

排查链路：这个坑几乎是每个用MySQL的Java项目都会碰到。我第一反应是时区问题，打开Navicat看数据库里的时间本身是正确的，然后看JDBC连接串，发现没有配置时区参数。JDBC默认使用服务器系统时区，而MySQL驱动的默认时区往往被识别为UTC，导致时间转换时少了8小时。

根因与解决：JDBC连接URL上加上时区参数：

url: jdbc:mysql://localhost:3306/pet_adoption?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false

注意useSSL=false也建议加上，本地开发环境用SSL握手反而会多出一些奇怪警告。

5.5 端口被占用：8080起不来了

现象：启动时报Port 8080 was already in use。

排查链路：这个非常常见，尤其是曾经跑过其他项目、或者IDEA调度器异常没有释放端口的情况。Windows下用netstat -ano | findstr 8080查占用端口的进程PID，然后去任务管理器确认，假如是我之前跑过的僵尸Java进程，直接结束掉。

根因与解决：如果端口确实被其他项目占用，最简单的方案是换一个端口：

server: port: 8081

如果频繁遇到“上次启动的进程没退出”，可以在IDEA的Run/Debug Configurations里配置热部署时的进程释放策略，或者直接改用Spring Boot DevTools。

5.6 修改了页面但刷新还是不生效

现象：改了Thymeleaf模板，刷新页面的效果没有变化。

排查链路：一开始我以为是浏览器缓存，强制刷新也没用。然后意识到Thymeleaf有模板缓存，默认情况会缓存解析后的模板，开发时非常碍事。

根因与解决：开发环境关闭模板缓存：

spring: thymeleaf: cache: false

但注意，如果打包部署到生产环境，这个配置要么删掉，要么设成true，否则每次请求都会重新解析模板，性能损耗明显。

5.7 Lombok的坑：IDEA环境下的连锁问题

现象：代码里用了@Data注解简化实体类，但编译报错找不到getter/setter方法。

排查链路：我先检查pom.xml是否引入Lombok依赖，确认引了；然后确认IDEA的Settings里Plugins搜索Lombok插件是否安装并启用；最后发现是项目导入时没有开启注解处理（Annotation Processing）。

根因与解决：IDEA使用Lombok需要三步——依赖引入、插件安装、开启Enable annotation processing。这三者缺一不可。很多人只做了前两步，就在IDEA里看到满屏的红色编译错误，其实根本不是代码问题。顺带一提，Lombok用起来虽爽，但面试时如果被问到，建议你诚实说明它只是编译期生成getter/setter的语法糖，并不影响运行时逻辑。

5.8 SQL中文乱码问题

现象：表单提交的中文保存到数据库后是问号或乱码。

排查链路：中文乱码的排查链一般有三个位置——页面编码、连接传输编码、数据库存储编码。我先确认HTML页面和模板是UTF-8，然后看JDBC连接串，最后检查数据库表字符集，发现表是latin1存储的。

根因与解决：在创建数据库时统一指定utf8mb4，这是兼容性最好的字符集，能存emoji表情，连接串里也显式声明编码：

CREATE DATABASE pet_adoption DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

另外SpringBoot的HttpMessageConverter默认UTF-8，一般不需要额外配置。如果用的是表单提交而不是JSON，确认页面里的accept-charset="UTF-8"即可。

6. 部署、测试和上线的最后一公里

6.1 本地跑起来的完整步骤

如果你拿到源码，第一件事不是读代码，而是把它跑起来。我给一个标准流程：

1. 准备数据库：用Navicat或命令行执行项目里的SQL脚本，创建库表和初始数据。注意SQL文件里有管理员账号和一个演示普通用户，初始密码建议用123456，登录后能改。
2. 改数据库配置：打开application.yml，把username/password改成你自己的，url里的数据库名要和建库时一致。
3. 启动项目：找到Application启动类，右键Run。看到Tomcat started on port(s): 8080就说明成功了。
4. 浏览器访问：打开localhost:8080，先走一遍用户流程——注册、登录、浏览宠物、提交领养申请；再用管理员账号登录，去后台审核。

这里有个经验：首次调试不要直接看代码，先在页面上把每个功能点一遍，把系统的整体流程走通。只有你知道“用户应该看到什么、管理员应该看到什么”，才能在代码和页面之间建立对应关系，否则看代码就像瞎子摸象。

6.2 演示和答辩前必须要准备的几个点

• 账号和演示数据：确保管理员和用户账号都能正常登录，宠物列表里至少有十几条不同分类的记录，数据要真实感强一点——别全是“一只猫”，品种、年龄、健康状况、描述都要填完整，导师一眼就能看出你是不是认真做的。
• 准备一条完整的业务链路：演示时不要求把所有功能点一次讲完，但这条链路——管理员发布宠物 → 用户提交申请 → 管理员审核通过 → 用户查看进度 ——必须畅通无阻，这是系统的灵魂。
• 准备好“异常演示”：比如去申请一只已经被认领的宠物，看系统如何处理报错提示。会演示异常处理往往比正常流程更能加印象分。

6.3 打包部署到云服务器的关键问题

本地跑通之后，如果想放到云服务器上，步骤也不复杂。先打包：

mvn clean package -DskipTests

然后看target目录下生成的jar包，上传到服务器，运行：

java -jar pet-adoption-system.jar

但这里有几个服务器特有的坑，我逐个提醒：

• 安全组端口：云服务器控制台的防火墙没放行8080端口，外网永远访问不到，本地却一切正常，这个排查方向一定要有。
• MySQL远程连接：服务器上的数据库要允许远程连接，并且给MySQL用户赋权，否则应用连不上库。部署时最稳妥的方案是让jar包和MySQL都在同一台服务器上，直接用localhost连接，少一层网络问题。
• 内存问题：如果你用的是2G内存的轻量服务器，JVM默认堆内存可能过大导致启动失败。加上参数限制：

java -Xms256m -Xmx512m -jar pet-adoption-system.jar

• 后台运行：直接java -jar关闭终端就停了，用nohup后台运行：

nohup java -jar pet-adoption-system.jar > app.log 2>&1 &

6.4 调试技巧：会看日志比会写代码更救命

整个调试过程里，最有用的习惯是看懂异常堆栈的第一行。很多人一看到报错就慌，复制整段到搜索引擎，其实90%的问题答案都在异常堆栈的前三行里——哪个类、哪个方法、哪一行代码出了问题，信息量非常充足。

遇到问题时我的标准流程是：先看堆栈定位到具体行号，再看上下文逻辑，然后看对应配置，最后才考虑去搜资料。如果堆栈看不懂，就手动在关键位置加日志输出或者断点走查，把流程里各个变量的值打出来。千万别一上来就东改西改，改半天往往把正常的代码也改坏了。

Spring Boot DevTools这个依赖我也建议加上，它提供了热部署能力，改完代码按一下F9自动重启，比每次手动重启快太多。但它只适合开发环境用，生产环境要移除。

7. 答辩和面试中，这个项目可以怎么讲出亮点

7.1 技术层面：不要只讲增删改查

说实话，一个管理系统的代码量并不大，如果你只回答“我实现了用户管理、宠物管理、申请管理”，那答辩和面试的观感就非常普通。你得把“为什么这么设计”讲出来，这才是拉开差距的地方。

我可以给你一组实实在在的问答方向：

Q：为什么用SpringBoot整合SSM，而不是单独用SSM或者直接用SpringBoot+MyBatis-Plus？

A：SpringBoot负责自动配置和依赖管理，SpringMVC负责请求路由，MyBatis负责SQL控制。三者的分工清晰，SpringBoot降低了配置成本，MyBatis保留了SQL的灵活性，对于业务逻辑包含状态流转的系统，这种方式让我能精确控制每一步SQL行为，比如用UPDATE pet SET status = 1 WHERE id = ? AND status = 0来实现并发场景下的防重复领养。

Q：领养申请审核时怎么处理并发问题？

A：如果两个申请同时被审核，都通过“先查再改”的逻辑会出问题。我的做法是在更新宠物状态时使用条件更新语句，通过影响行数判断是否被人抢先更新，这也是乐观锁思想的落地。核心代码就是我上面展示的updateStatusIfAvailable方法。

Q：拦截器和过滤器的区别？

A：过滤器是Servlet规范中的概念，在请求进入Servlet容器后、进入Servlet前执行，作用域更广；拦截器是SpringMVC的组件，基于HandlerMapping和HandlerAdapter，可以拿到Handler方法信息，还可以通过HandlerInterceptor的preHandle/postHandle/afterCompletion在请求处理前后分别执行逻辑。这套系统里我用拦截器做登录和管理员权限校验，放行规则写在addInterceptors方法里。

Q：事务失效的常见场景有哪些？

A：@Transactional默认只在运行时异常时回滚，如果方法被内部调用this调用而不是通过代理调用，事务会失效；如果是非public方法、异常被catch吞掉、或者方法名里用了try-catch抛了检查异常而没指定rollbackFor，也会失效。做这个项目时我在Service层对“提交申请”“审核通过”两个关键业务方法加了事务，并特意验证了异常情况下数据是否回滚。

这些问答你提前准备一遍，比临时翻书有效得多。

7.2 业务层面：一个系统的价值在流程设计

项目答辩时最容易回答不出来的问题是“你这个系统相比线下手工操作，核心价值在哪里”。这个问题的答案不是“数据存数据库了”，而是——

• 信息的集中可见：所有待领养宠物统一展示，搜索、分类、详情一键到位，让合适的宠物能被合适的人看到。
• 流程线上化留痕：谁在什么时间申请、管理员什么时间审核、审核意见是什么，全流程记录在库，不用担心纸质表丢失或者口头承诺没依据。
• 防重复领养机制：通过状态控制和条件更新，从技术上保证了同一只宠物不会被两个申请者同时认领成功。
• 可追溯、可回访：每一只宠物的领养人、联系电话、申请理由都有记录，方便后续做回访和追踪。

这样一讲，你的系统就不只是一堆CRUD页面，而是一个真正解决业务问题的工具，导师和面试官想质疑都找不到角度。

7.3 后续扩展思路：这个项目还能长出什么

如果还有余力，有几个扩展方向都能快速增加项目的亮点：

• 给系统加一个微信小程序端：用户从小程序里浏览宠物、提交申请，后台复用现有接口，面试时可以说“我为系统设计了第二个客户端，基于微信生态降低了用户使用门槛”。
• 增加消息通知机制：审核通过或拒绝后，给站内信或邮件通知用户，体现流程闭环意识。
• 用定时任务做领养回访提醒：SpringBoot自带@Scheduled调度器，领养成功30天后自动生成回访任务，提醒管理员联系领养人。
• 宠物档案扩展：给宠物增加疫苗接种记录、驱虫记录，形成更完整的健康档案。

当然，这些扩展不是为了做而做，而是要能在文档和答辩里讲清楚“它解决了什么新问题”。加一个功能却讲不出业务价值，反而减分。

8. 一些实际项目里才有的心得

写到这儿，我想把做这个项目最值得说的几条经验单独拎出来，也是我个人在实际开发过程中体会最深的部分。

第一条心得是：先画流程图，再写代码，哪怕只是画在草稿纸上。我当时第一部分代码就直接从用户模块开始写，写到领养申请状态流转时，发现自己反复改表结构，因为状态怎么走根本没想清楚。后来停下来把“提交申请→审核→领养成功/拒绝”的每个分支画清楚，代码反而一晚上就理顺了。

第二条心得是：状态字段的设计决定系统的复杂度上限。用数字编码状态、单独字段管理宠物状态与申请状态，这个决策在后来的扩展中带来的收益远超想象。一旦你陷入“用字符串描述状态、一个字段管到底”的做法，系统越往后改越痛苦。

第三条心得是：把代码写“给别人看”比写“给自己跑通”更重要。毕业设计和真实项目最大的区别在于，代码是要被讲解、被评审的。包名规范、Controller、Service、Mapper分层清晰、关键方法写注释，这些习惯会让你在答辩前名单上少费一百倍口水。我见过太多功能跑通但代码混乱的现场，作者讲着讲着被导师一句“你这个Controller为什么写了三百行”问得哑口无言。按时分层、克制散装代码，这本身就是专业性的体现。

如果你正在做这个项目，我真心建议你把第四章里的并发防重逻辑吃透——这是整个系统里技术含金量最高的一段，也是面试官最可能追问的一个点。把它讲明白了，这个项目在你履历里的价值立刻不一样。

以上都是我实际做项目时的经验，希望对你有帮助。