做这类型项目有个特别有意思的地方看着名字平平无奇真的动手做完你会发现它把后端开发该踩的坑几乎全踩了一遍。宠物领养管理系统是我这几年给不少同学做课程设计和毕设时反复接触的选题核心痛点其实很实在——流浪动物救助站的信息大多散落在微信群和Excel表里领养人想问清楚一只宠物的状态得来回私聊管理员重复上传照片、登记信息累且容易出错。这套系统要解决的就是把这个碎片化流程搬到Web端和移动端用户按品种、年龄、健康状态筛选宠物在线提交领养申请管理员在后台统一维护宠物档案、审核申请、管理公告。对开发者来说它又是一个麻雀虽小五脏俱全的练手项目权限控制、分页查询、文件上传、状态流转、定时任务这些常见考点全部能在一个项目里串起来。不管你是在准备毕业设计的在校生还是学完Java基础想找个完整项目提升自己的开发者跟着这篇文章把整个实现思路过一遍收获会远超“能跑起来”这个层面。1. 项目定位与方案选型的四个关键判断1.1 先分清两类角色和四条业务闭环做宠物领养管理系统第一件事不是写代码而是把“谁在用”“用哪些功能”“流程怎么流转”这三件事想明白。系统里的角色就两类普通用户和管理员。普通用户做的事情很集中注册登录、浏览宠物列表、查看宠物详情、收藏或提交领养申请、查看自己申请的审核进度。听上去简单但这里有一个业务闭环用户看到的宠物信息必须实时可信否则“申请领养”这个动作就失去了意义。管理员做的事情稍微多些维护宠物信息新增、编辑、下架、审核用户的领养申请、管理用户账号、发布公告、维护宠物分类。管理员端也有一条闭环用户提交申请之后管理员要审核审核通过后标记宠物为“已被领养”最后可能还有一段回访记录要登记。这两条闭环咬合在一起系统才算完整。我画过很多次这个项目的脑图最后总结出的核心模块就六个用户模块、宠物模块、领养申请模块、公告模块、分类模块、数据统计模块。别觉得少这六个模块足够撑起一个结构清晰的Spring Boot项目而且每个模块都能拆出独立接口方便后续扩展小程序端。1.2 Spring Boot到底赢在哪里选Spring Boot而不是老式的Spring MVC加XML配置理由不用讲太多大道理就一个省心。以前写Spring项目最让人崩溃的就是配置文件——数据源、事务、组件扫描、视图解析器每个都要手工配置稍有版本不一致就报各种玄学错误。Spring Boot把绝大多数自动配置都内置好了内嵌Tomcat容器依赖引入也精简了不少。我第一次用Spring Boot做这类项目时从零建工程到后端接口能通前后不到半天这在SSH时代是不可想象的。可能有同学会担心自动配置太多反而不理解底层原理。我的建议是先跑起来再回头看源码。你用了spring-boot-starter-web就去看看它自动配置了哪些东西你用了Spring Data JPA就看看它是怎么根据实体类生成Repository的。这种“先用后懂”的学习路径比一开始硬啃源码高效得多。1.3 JPA还是MyBatis按团队习惯来数据访问层是每个Spring Boot项目都要做的选择。宠物领养管理系统这个规模的项目用Spring Data JPA完全足够它的优势是实体类即表结构CRUD不用写SQL分页也简单Pageable一出PagePet就回来了。对于不擅长SQL的同学JPA的学习曲线友好很多。如果是公司里多人协作的正式项目可能更多人会用MyBatis原因是SQL可控性好复杂查询优化起来方便。我的经验是毕设或者个人练手项目选JPA因为代码量小、出活快如果你已经在实际工作中习惯了MyBatis那继续用也行不影响整体设计。这个项目里我按JPA来写后文所有代码示例也都是基于JPA的。1.4 登录鉴权JWT加拦截器足够了很多人纠结要不要上Spring Security。宠物领养管理系统虽然有两类角色但整体权限粒度并不细用Spring Security会有种“杀鸡用牛刀”的感觉配置复杂新手折腾容易劝退。更务实的方案是用JWT做无状态登录用拦截器做登录校验和角色校验。具体做法其实很清晰用户登录成功后后端生成一个JWT令牌返回给前端前端把令牌存起来之后每次请求都放在Header里带上。拦截器负责解析令牌把用户信息塞到请求上下文里再用一个小小的注解标记“这个接口需要管理员权限”在拦截器里统一判断。这套方案代码量不大逻辑也直观还能顺便把“防止普通用户调用管理接口”这个问题解决了。2. 数据库设计六张核心表和一套状态机2.1 用户表基础字段不要贪多数据库设计是这类系统最容易返工的地方我见过有人一上来就设计出十几张表结果业务一跑就发现全是冗余。宠物领养管理系统真正刚需的表其实是六张用户表、宠物表、领养申请表、公告表、分类表以及一个回访记录表。用户表别贪多常规字段就够用id、用户名、密码、昵称、手机号、头像、角色、注册时间。要注意两点一是密码必须加密存储用BCrypt或者SHA-256加盐都行千万别明文入库二是用户名要加唯一约束否则注册接口会被刷出大量重复账号。CREATE TABLE user ( id INT NOT NULL AUTO_INCREMENT, username VARCHAR(50) NOT NULL, password VARCHAR(100) NOT NULL, nickname VARCHAR(50) DEFAULT NULL, phone VARCHAR(20) DEFAULT NULL, avatar VARCHAR(255) DEFAULT NULL, role TINYINT DEFAULT 0 COMMENT 0-普通用户 1-管理员, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_username (username) );2.2 宠物表状态字段直接决定业务走向宠物表是系统的核心表字段需要仔细规划id、名称、品种、年龄、性别、是否绝育、疫苗情况、健康状态、图片地址、描述、分类id、状态、创建时间。这里特别说一下“状态”字段它直接决定业务流程的方向。我的建议是宠物的状态至少分成四种可领养、审核中、已领养、已下架。其中“审核中”其实不是宠物本身的属性而是当它有一条进行中的领养申请时前端展示上应该给用户一个明确提示避免同一只宠物被多人同时申请时产生混乱。宠物图片不要直接落数据库存二进制存一个URL或者相对路径就够了文件本体放在本地磁盘目录或对象存储服务上。这样表结构清爽查询压力也小。2.3 领养申请表核心中的核心领养申请表是整套系统的业务枢纽字段包括id、宠物id、用户id、申请理由、联系电话、状态、申请时间、审核时间、审核备注。这里最需要注意的是状态设计。领养申请的状态通常有四种待审核、审核通过、已驳回、已完成回访结束。强烈建议用字符串常量或者枚举来管理而不是用魔法数字。魔法数字写起来省事但两个月后你自己都记不住1和2分别代表什么意思。// 前端联调时也会用到建议前后端统一状态名 const APPLY_STATUS { PENDING: 待审核, APPROVED: 审核通过, REJECTED: 已驳回, FINISHED: 已完成 };2.4 公告表、分类表和回访记录表公告表字段很简单id、标题、内容、发布时间、状态。分类表更简单id、分类名称、描述。回访记录表需要稍微想一想它是挂在领养申请下面的子表字段包括id、申请id、回访内容、回访时间、回访人。这六张表设计完成后关系其实很清晰用户和宠物是一对多的关系用户和领养申请是一对多的关系宠物和领养申请在某个时间段内是一对一的关系领养申请和回访记录是一对多的关系。理清这些关系后面写JPA实体映射时就非常顺畅。2.5 为什么状态要用枚举而不是布尔值很多新手容易犯一个错误给宠物加一个is_adopted布尔字段领养通过就置成true驳回就置成false。这个设计在真实场景里是撑不住的因为状态不是非黑即白的——宠物可能处于下架状态也可能同时被多个人咨询。用一个状态字段而不用布尔值能够承载更丰富的业务流程也为以后的业务扩展留了余地。同理领养申请的状态也不该只有“通过”和“不通过”中间的“待审核”和“回访完成”都是有业务意义的。3. 后端核心功能落地从实体类到接口的完整过程3.1 工程目录与分层规范平时接这类项目我习惯把后端工程按controller、service、repository、entity、config、common几个包拆开。不是搞形式主义而是当接口数量超过二十个以后按分层找代码会比在一堆类里翻快得多。com.example.petadopt ├── controller # 接口层只做参数接收和返回 ├── service # 业务逻辑层处理校验和流程 ├── repository # 数据访问层继承JpaRepository ├── entity # 实体类对应数据库表 ├── config # 配置类比如CORS配置、拦截器注册 └── common # 通用返回值、异常处理、工具类3.2 宠物实体类与Repository实现实体类直接用JPA注解映射代码很直观。Entity Table(name pet) public class Pet { Id GeneratedValue(strategy GenerationType.IDENTITY) private Integer id; private String name; private String breed; private Integer age; private String gender; private String healthStatus; private String picture; private String description; Column(name category_id) private Integer categoryId; private String status; Column(name create_time) private LocalDateTime createTime; // getter / setter 省略 }Repository层继承JpaRepository之后基础CRUD和分页查询就全有了。Repository public interface PetRepository extends JpaRepositoryPet, Integer { PagePet findByStatus(String status, Pageable pageable); PagePet findByStatusAndBreedContaining(String status, String breed, Pageable pageable); long countByStatus(String status); }3.3 领养申请业务逻辑的服务层实现业务逻辑是这套系统的重头戏我直接给一个最核心的方法提交领养申请。这个方法看起来简单实际上要处理三个边界条件宠物必须存在且状态为可领养、用户不能重复申请同一只宠物、申请理由不能为空。Service public class AdoptApplyServiceImpl implements AdoptApplyService { Autowired private PetRepository petRepository; Autowired private AdoptApplyRepository applyRepository; Override Transactional public AdoptApply submitApply(AdoptApplyVO vo, Integer userId) { Pet pet petRepository.findById(vo.getPetId()) .orElseThrow(() - new BusinessException(宠物不存在)); if (!可领养.equals(pet.getStatus())) { throw new BusinessException(该宠物当前暂不可申请领养); } // 防止重复申请同一个用户对同一只宠物只能有一条进行中的申请 boolean exists applyRepository.existsByPetIdAndUserIdAndStatus( vo.getPetId(), userId, 待审核); if (exists) { throw new BusinessException(您已提交过申请请等待审核结果); } AdoptApply apply new AdoptApply(); apply.setPetId(pet.getId()); apply.setUserId(userId); apply.setReason(vo.getReason()); apply.setPhone(vo.getPhone()); apply.setStatus(待审核); apply.setCreateTime(LocalDateTime.now()); return applyRepository.save(apply); } }这里有几个细节值得展开。Transactional一定要加上因为“检查申请是否重复”和“新申请入库”之间存在时间窗口加事务能把这两步绑定在一起。另外我在校验里面专门做了“宠物状态”的检查这个检查能拦截一种非常常见的错误场景宠物已经被别的用户领走后另一个用户仍然提交申请。审核领养申请的逻辑同样要处理状态流转。管理员审核通过后不仅要更新申请单的状态还要同步把宠物的状态改成“已领养”这两个动作必须放在同一个事务里否则会出现申请单显示已通过、宠物却依然显示可领养的脏数据。Transactional public void approveApply(Integer applyId) { AdoptApply apply applyRepository.findById(applyId) .orElseThrow(() - new BusinessException(申请记录不存在)); apply.setStatus(审核通过); apply.setAuditTime(LocalDateTime.now()); applyRepository.save(apply); Pet pet petRepository.findById(apply.getPetId()).orElse(null); if (pet ! null) { pet.setStatus(已领养); petRepository.save(pet); } }3.4 控制层接口设计与参数校验接口层的设计原则是“薄”——只做参数接收、校验、调用Service、返回结果。宠物查询接口用Pageable接收分页参数省得自己手动解析页码和每页条数。RestController RequestMapping(/api/pet) public class PetController { Autowired private PetService petService; GetMapping(/list) public ResultPagePetVO list( RequestParam(defaultValue 1) int pageNum, RequestParam(defaultValue 10) int pageSize, RequestParam(required false) String keyword, RequestParam(required false) String categoryId) { PagePetVO data petService.queryPage(pageNum, pageSize, keyword, categoryId); return Result.success(data); } GetMapping(/{id}) public ResultPetVO detail(PathVariable Integer id) { return Result.success(petService.getDetail(id)); } }参数校验方面我推荐用JSR-303注解加在VO上比如NotBlank、NotNull然后在Controller参数前加Validated触发校验。这样比自己在方法体里写一堆if判断干净得多。不过要注意Validated校验失败抛出异常后前端收到的报文格式需要统一所以别忘了在全局异常处理器里把这个异常转成统一的Result结构。3.5 登录接口与拦截器注册登录逻辑不复杂但有几个细节容易踩坑。用户输入密码后要用BCrypt的matches方法去比对而不是把数据库里的密文解密回来再比较。同时判断角色的时候要用数据库里存的role字段不能直接信任前端传过来的角色参数。PostMapping(/login) public ResultLoginVO login(RequestBody LoginDTO dto) { User user userRepository.findByUsername(dto.getUsername()); if (user null || !passwordEncoder.matches(dto.getPassword(), user.getPassword())) { throw new BusinessException(用户名或密码错误); } String token jwtUtil.createToken(user.getId(), user.getUsername(), user.getRole()); return Result.success(new LoginVO(token, user)); }拦截器这里用的是HandlerInterceptor注册的时候要注意排除登录、注册、宠物查询这类不需要鉴权的接口否则会把自己挡在门外。Configuration public class WebConfig implements WebMvcConfigurer { Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(new LoginInterceptor()) .addPathPatterns(/api/**) .excludePathPatterns(/api/user/login, /api/user/register, /api/pet/list, /api/pet/*); } }4. 管理后台、小程序端与部署上线的延伸方案4.1 管理后台快速搭建的几个思路管理后台不一定非要单独开发一个前端工程可以用更轻量的方案如果只是毕设展示直接用Vue加Element Plus写一个管理页面接口对接后端的/admin前缀接口就行如果时间紧也可以使用现成的后台管理框架比如若依这类脚手架改一改菜单和页面就能适配。无论选哪种方案管理后台的接口都建议单独加一个角色校验逻辑。管理员接口不应该放在和用户接口同一个路径下面而是在路径上做区分比如/api/admin/pet/add这样拦截器里判断起来很清晰。4.2 小程序端对接的思路和隐形坑很多人的毕设要求里带“小程序”三个字其实用uni-app写一套小程序端是性价比很高的方式因为同一套代码可以编译到微信小程序、H5和其他平台不需要为每个平台单独重新开发。小程序端对接Spring Boot后端时最大的坑在跨域和鉴权。如果你是线上测试域名必须配置合法证书否则小程序请求会被拦截如果你是本地开发调试可以用开发者工具的“不校验合法域名”选项临时绕过但这个只能用来开发不能到上线阶段还开着。小程序端的登录有自己的体系建议做法是小程序端调用微信登录获取code后端拿这个code调用微信接口换取openid然后用自己的逻辑创建或关联系统用户再生成JWT返回给小程序。这样才能把小程序用户和系统的用户表打通。4.3 部署上线与文件存储的实操建议到了部署环节很多人才发现开发环境一切正常一到服务器上就各种起不来。最基本的三件事确认服务器装了对应版本的JDK、确认MySQL的字符集是utf8mb4、确认防火墙放行了8080端口。宠物图片的存储开发环境可以直接放到本地磁盘目录比如/var/pet-images给Nginx做一个静态资源映射就可以访问。如果要上云直接用对象存储服务存文件名把访问域名存到数据库里这样代码里基本不用改路径逻辑。Spring Boot项目打包成jar后可以用一行命令启动nohup java -jar pet-adopt-system.jar --server.port8080 app.log 21 日志输出到文件里出问题时直接看日志比看控制台方便得多。我建议所有第一次部署的同学先学会看启动日志中的“Started Application in x seconds”这句话看着它出现再考虑下一步调接口的事。5. 高频踩坑记录与排查速查表长期帮人看这类项目的代码我发现很多问题其实是反复出现的总结成一份备查手册能帮你少走很多弯路。5.1 启动阶段的经典报错端口被占用是最常见的。默认8080端口经常被其他进程抢走报错信息一般是Port 8080 was already in use。解决办法要么换端口启动要么找出占用的进程干掉。数据库连接失败要先分清楚是驱动没加、地址写错、还是权限不对。Spring Boot连接MySQL需要加上mysql-connector-j依赖这就经常有人漏掉。另外如果数据库地址写的是localhost而驱动版本太高也可能报连接错误统一改成127.0.0.1加正确端口一般能解决。Bean创建失败往往是Entity里字段名和数据库列名对不上JPA在启动校验时会直接报错。遇到这个错误别急着怀疑配置先检查实体类的Column(namexxx)。5.2 数据层和时间字段的幺蛾子JPA的LocalDateTime字段有序列化问题返回给前端时默认可能带一段冗长的序列化结果或者格式不符合前端预期。解决办法是在配置里指定全局的日期格式或者给字段加JsonFormat注解。spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8还有一个时区问题很隐蔽服务器默认时区不是东八区的话new Date()插入数据库的时间会比本地晚8个小时。如果你发现入库时间不对先检查MySQL的连接参数里是否加了serverTimezoneAsia/Shanghai。5.3 领养流程里的边界情况处理重复申请的问题是这类系统的高频bug。用户点了一次申请没有反馈又点了一次结果生成两条申请记录。解决办法其实写在了业务代码里在保存前查询“是否存在同宠物同用户的待审核记录”。但这还不算最隐蔽的最隐蔽的是审核通过后宠物的状态没同步更新导致“已领养”的宠物还在列表里展示。这两个问题本质上都是“状态一致性”没处理好。5.4 安全与并发方面的几点提醒安全方面最重要的三件事密码必须加密存储、数据库操作不能用字符串拼接SQL、管理接口必须做角色校验。这三点没做到系统被日穿只是时间问题。并发方面的提醒是如果真遇到多个人同时对同一只宠物提交申请的极端情况可以考虑在申请人提交时锁一下宠物记录或者加个乐观锁字段虽然对于一般规模的毕设项目完全用不上但面试时能答出这个场景会让面试官觉得你真的想过这些问题。5.5 排查问题的推荐顺序后端接口出问题我建议不要盯着代码看用效率更快的排查链条先看接口请求是否到达了后端再查Controller是否正确接收参数接着看Service层的日志、SQL语句最后才是检查数据库数据。一套下来90%的问题都能定位到。前端出问题优先打开浏览器开发者工具的Network面板看接口状态码405就是路径或请求方式不对500就是后端异常401或者403就是登录鉴权出了问题。最后按我的个人习惯给正在做这类项目的朋友一点建议代码能跑只是起点真正值得花时间的是把流程和状态梳理清楚。你可以试着把整个系统的操作日志从用户注册、浏览宠物、提交申请、管理员审核、回访登记串起来在纸上画出每一个状态的变化。这件事做完哪怕是面试的时候被问到“领养审核通过了宠物状态怎么变”你也能不假思索答出来。这比死记硬背一堆面试题靠谱得多。
宠物领养管理系统实战：Spring Boot + JWT + JPA 全栈实现
做这类型项目有个特别有意思的地方看着名字平平无奇真的动手做完你会发现它把后端开发该踩的坑几乎全踩了一遍。宠物领养管理系统是我这几年给不少同学做课程设计和毕设时反复接触的选题核心痛点其实很实在——流浪动物救助站的信息大多散落在微信群和Excel表里领养人想问清楚一只宠物的状态得来回私聊管理员重复上传照片、登记信息累且容易出错。这套系统要解决的就是把这个碎片化流程搬到Web端和移动端用户按品种、年龄、健康状态筛选宠物在线提交领养申请管理员在后台统一维护宠物档案、审核申请、管理公告。对开发者来说它又是一个麻雀虽小五脏俱全的练手项目权限控制、分页查询、文件上传、状态流转、定时任务这些常见考点全部能在一个项目里串起来。不管你是在准备毕业设计的在校生还是学完Java基础想找个完整项目提升自己的开发者跟着这篇文章把整个实现思路过一遍收获会远超“能跑起来”这个层面。1. 项目定位与方案选型的四个关键判断1.1 先分清两类角色和四条业务闭环做宠物领养管理系统第一件事不是写代码而是把“谁在用”“用哪些功能”“流程怎么流转”这三件事想明白。系统里的角色就两类普通用户和管理员。普通用户做的事情很集中注册登录、浏览宠物列表、查看宠物详情、收藏或提交领养申请、查看自己申请的审核进度。听上去简单但这里有一个业务闭环用户看到的宠物信息必须实时可信否则“申请领养”这个动作就失去了意义。管理员做的事情稍微多些维护宠物信息新增、编辑、下架、审核用户的领养申请、管理用户账号、发布公告、维护宠物分类。管理员端也有一条闭环用户提交申请之后管理员要审核审核通过后标记宠物为“已被领养”最后可能还有一段回访记录要登记。这两条闭环咬合在一起系统才算完整。我画过很多次这个项目的脑图最后总结出的核心模块就六个用户模块、宠物模块、领养申请模块、公告模块、分类模块、数据统计模块。别觉得少这六个模块足够撑起一个结构清晰的Spring Boot项目而且每个模块都能拆出独立接口方便后续扩展小程序端。1.2 Spring Boot到底赢在哪里选Spring Boot而不是老式的Spring MVC加XML配置理由不用讲太多大道理就一个省心。以前写Spring项目最让人崩溃的就是配置文件——数据源、事务、组件扫描、视图解析器每个都要手工配置稍有版本不一致就报各种玄学错误。Spring Boot把绝大多数自动配置都内置好了内嵌Tomcat容器依赖引入也精简了不少。我第一次用Spring Boot做这类项目时从零建工程到后端接口能通前后不到半天这在SSH时代是不可想象的。可能有同学会担心自动配置太多反而不理解底层原理。我的建议是先跑起来再回头看源码。你用了spring-boot-starter-web就去看看它自动配置了哪些东西你用了Spring Data JPA就看看它是怎么根据实体类生成Repository的。这种“先用后懂”的学习路径比一开始硬啃源码高效得多。1.3 JPA还是MyBatis按团队习惯来数据访问层是每个Spring Boot项目都要做的选择。宠物领养管理系统这个规模的项目用Spring Data JPA完全足够它的优势是实体类即表结构CRUD不用写SQL分页也简单Pageable一出PagePet就回来了。对于不擅长SQL的同学JPA的学习曲线友好很多。如果是公司里多人协作的正式项目可能更多人会用MyBatis原因是SQL可控性好复杂查询优化起来方便。我的经验是毕设或者个人练手项目选JPA因为代码量小、出活快如果你已经在实际工作中习惯了MyBatis那继续用也行不影响整体设计。这个项目里我按JPA来写后文所有代码示例也都是基于JPA的。1.4 登录鉴权JWT加拦截器足够了很多人纠结要不要上Spring Security。宠物领养管理系统虽然有两类角色但整体权限粒度并不细用Spring Security会有种“杀鸡用牛刀”的感觉配置复杂新手折腾容易劝退。更务实的方案是用JWT做无状态登录用拦截器做登录校验和角色校验。具体做法其实很清晰用户登录成功后后端生成一个JWT令牌返回给前端前端把令牌存起来之后每次请求都放在Header里带上。拦截器负责解析令牌把用户信息塞到请求上下文里再用一个小小的注解标记“这个接口需要管理员权限”在拦截器里统一判断。这套方案代码量不大逻辑也直观还能顺便把“防止普通用户调用管理接口”这个问题解决了。2. 数据库设计六张核心表和一套状态机2.1 用户表基础字段不要贪多数据库设计是这类系统最容易返工的地方我见过有人一上来就设计出十几张表结果业务一跑就发现全是冗余。宠物领养管理系统真正刚需的表其实是六张用户表、宠物表、领养申请表、公告表、分类表以及一个回访记录表。用户表别贪多常规字段就够用id、用户名、密码、昵称、手机号、头像、角色、注册时间。要注意两点一是密码必须加密存储用BCrypt或者SHA-256加盐都行千万别明文入库二是用户名要加唯一约束否则注册接口会被刷出大量重复账号。CREATE TABLE user ( id INT NOT NULL AUTO_INCREMENT, username VARCHAR(50) NOT NULL, password VARCHAR(100) NOT NULL, nickname VARCHAR(50) DEFAULT NULL, phone VARCHAR(20) DEFAULT NULL, avatar VARCHAR(255) DEFAULT NULL, role TINYINT DEFAULT 0 COMMENT 0-普通用户 1-管理员, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_username (username) );2.2 宠物表状态字段直接决定业务走向宠物表是系统的核心表字段需要仔细规划id、名称、品种、年龄、性别、是否绝育、疫苗情况、健康状态、图片地址、描述、分类id、状态、创建时间。这里特别说一下“状态”字段它直接决定业务流程的方向。我的建议是宠物的状态至少分成四种可领养、审核中、已领养、已下架。其中“审核中”其实不是宠物本身的属性而是当它有一条进行中的领养申请时前端展示上应该给用户一个明确提示避免同一只宠物被多人同时申请时产生混乱。宠物图片不要直接落数据库存二进制存一个URL或者相对路径就够了文件本体放在本地磁盘目录或对象存储服务上。这样表结构清爽查询压力也小。2.3 领养申请表核心中的核心领养申请表是整套系统的业务枢纽字段包括id、宠物id、用户id、申请理由、联系电话、状态、申请时间、审核时间、审核备注。这里最需要注意的是状态设计。领养申请的状态通常有四种待审核、审核通过、已驳回、已完成回访结束。强烈建议用字符串常量或者枚举来管理而不是用魔法数字。魔法数字写起来省事但两个月后你自己都记不住1和2分别代表什么意思。// 前端联调时也会用到建议前后端统一状态名 const APPLY_STATUS { PENDING: 待审核, APPROVED: 审核通过, REJECTED: 已驳回, FINISHED: 已完成 };2.4 公告表、分类表和回访记录表公告表字段很简单id、标题、内容、发布时间、状态。分类表更简单id、分类名称、描述。回访记录表需要稍微想一想它是挂在领养申请下面的子表字段包括id、申请id、回访内容、回访时间、回访人。这六张表设计完成后关系其实很清晰用户和宠物是一对多的关系用户和领养申请是一对多的关系宠物和领养申请在某个时间段内是一对一的关系领养申请和回访记录是一对多的关系。理清这些关系后面写JPA实体映射时就非常顺畅。2.5 为什么状态要用枚举而不是布尔值很多新手容易犯一个错误给宠物加一个is_adopted布尔字段领养通过就置成true驳回就置成false。这个设计在真实场景里是撑不住的因为状态不是非黑即白的——宠物可能处于下架状态也可能同时被多个人咨询。用一个状态字段而不用布尔值能够承载更丰富的业务流程也为以后的业务扩展留了余地。同理领养申请的状态也不该只有“通过”和“不通过”中间的“待审核”和“回访完成”都是有业务意义的。3. 后端核心功能落地从实体类到接口的完整过程3.1 工程目录与分层规范平时接这类项目我习惯把后端工程按controller、service、repository、entity、config、common几个包拆开。不是搞形式主义而是当接口数量超过二十个以后按分层找代码会比在一堆类里翻快得多。com.example.petadopt ├── controller # 接口层只做参数接收和返回 ├── service # 业务逻辑层处理校验和流程 ├── repository # 数据访问层继承JpaRepository ├── entity # 实体类对应数据库表 ├── config # 配置类比如CORS配置、拦截器注册 └── common # 通用返回值、异常处理、工具类3.2 宠物实体类与Repository实现实体类直接用JPA注解映射代码很直观。Entity Table(name pet) public class Pet { Id GeneratedValue(strategy GenerationType.IDENTITY) private Integer id; private String name; private String breed; private Integer age; private String gender; private String healthStatus; private String picture; private String description; Column(name category_id) private Integer categoryId; private String status; Column(name create_time) private LocalDateTime createTime; // getter / setter 省略 }Repository层继承JpaRepository之后基础CRUD和分页查询就全有了。Repository public interface PetRepository extends JpaRepositoryPet, Integer { PagePet findByStatus(String status, Pageable pageable); PagePet findByStatusAndBreedContaining(String status, String breed, Pageable pageable); long countByStatus(String status); }3.3 领养申请业务逻辑的服务层实现业务逻辑是这套系统的重头戏我直接给一个最核心的方法提交领养申请。这个方法看起来简单实际上要处理三个边界条件宠物必须存在且状态为可领养、用户不能重复申请同一只宠物、申请理由不能为空。Service public class AdoptApplyServiceImpl implements AdoptApplyService { Autowired private PetRepository petRepository; Autowired private AdoptApplyRepository applyRepository; Override Transactional public AdoptApply submitApply(AdoptApplyVO vo, Integer userId) { Pet pet petRepository.findById(vo.getPetId()) .orElseThrow(() - new BusinessException(宠物不存在)); if (!可领养.equals(pet.getStatus())) { throw new BusinessException(该宠物当前暂不可申请领养); } // 防止重复申请同一个用户对同一只宠物只能有一条进行中的申请 boolean exists applyRepository.existsByPetIdAndUserIdAndStatus( vo.getPetId(), userId, 待审核); if (exists) { throw new BusinessException(您已提交过申请请等待审核结果); } AdoptApply apply new AdoptApply(); apply.setPetId(pet.getId()); apply.setUserId(userId); apply.setReason(vo.getReason()); apply.setPhone(vo.getPhone()); apply.setStatus(待审核); apply.setCreateTime(LocalDateTime.now()); return applyRepository.save(apply); } }这里有几个细节值得展开。Transactional一定要加上因为“检查申请是否重复”和“新申请入库”之间存在时间窗口加事务能把这两步绑定在一起。另外我在校验里面专门做了“宠物状态”的检查这个检查能拦截一种非常常见的错误场景宠物已经被别的用户领走后另一个用户仍然提交申请。审核领养申请的逻辑同样要处理状态流转。管理员审核通过后不仅要更新申请单的状态还要同步把宠物的状态改成“已领养”这两个动作必须放在同一个事务里否则会出现申请单显示已通过、宠物却依然显示可领养的脏数据。Transactional public void approveApply(Integer applyId) { AdoptApply apply applyRepository.findById(applyId) .orElseThrow(() - new BusinessException(申请记录不存在)); apply.setStatus(审核通过); apply.setAuditTime(LocalDateTime.now()); applyRepository.save(apply); Pet pet petRepository.findById(apply.getPetId()).orElse(null); if (pet ! null) { pet.setStatus(已领养); petRepository.save(pet); } }3.4 控制层接口设计与参数校验接口层的设计原则是“薄”——只做参数接收、校验、调用Service、返回结果。宠物查询接口用Pageable接收分页参数省得自己手动解析页码和每页条数。RestController RequestMapping(/api/pet) public class PetController { Autowired private PetService petService; GetMapping(/list) public ResultPagePetVO list( RequestParam(defaultValue 1) int pageNum, RequestParam(defaultValue 10) int pageSize, RequestParam(required false) String keyword, RequestParam(required false) String categoryId) { PagePetVO data petService.queryPage(pageNum, pageSize, keyword, categoryId); return Result.success(data); } GetMapping(/{id}) public ResultPetVO detail(PathVariable Integer id) { return Result.success(petService.getDetail(id)); } }参数校验方面我推荐用JSR-303注解加在VO上比如NotBlank、NotNull然后在Controller参数前加Validated触发校验。这样比自己在方法体里写一堆if判断干净得多。不过要注意Validated校验失败抛出异常后前端收到的报文格式需要统一所以别忘了在全局异常处理器里把这个异常转成统一的Result结构。3.5 登录接口与拦截器注册登录逻辑不复杂但有几个细节容易踩坑。用户输入密码后要用BCrypt的matches方法去比对而不是把数据库里的密文解密回来再比较。同时判断角色的时候要用数据库里存的role字段不能直接信任前端传过来的角色参数。PostMapping(/login) public ResultLoginVO login(RequestBody LoginDTO dto) { User user userRepository.findByUsername(dto.getUsername()); if (user null || !passwordEncoder.matches(dto.getPassword(), user.getPassword())) { throw new BusinessException(用户名或密码错误); } String token jwtUtil.createToken(user.getId(), user.getUsername(), user.getRole()); return Result.success(new LoginVO(token, user)); }拦截器这里用的是HandlerInterceptor注册的时候要注意排除登录、注册、宠物查询这类不需要鉴权的接口否则会把自己挡在门外。Configuration public class WebConfig implements WebMvcConfigurer { Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(new LoginInterceptor()) .addPathPatterns(/api/**) .excludePathPatterns(/api/user/login, /api/user/register, /api/pet/list, /api/pet/*); } }4. 管理后台、小程序端与部署上线的延伸方案4.1 管理后台快速搭建的几个思路管理后台不一定非要单独开发一个前端工程可以用更轻量的方案如果只是毕设展示直接用Vue加Element Plus写一个管理页面接口对接后端的/admin前缀接口就行如果时间紧也可以使用现成的后台管理框架比如若依这类脚手架改一改菜单和页面就能适配。无论选哪种方案管理后台的接口都建议单独加一个角色校验逻辑。管理员接口不应该放在和用户接口同一个路径下面而是在路径上做区分比如/api/admin/pet/add这样拦截器里判断起来很清晰。4.2 小程序端对接的思路和隐形坑很多人的毕设要求里带“小程序”三个字其实用uni-app写一套小程序端是性价比很高的方式因为同一套代码可以编译到微信小程序、H5和其他平台不需要为每个平台单独重新开发。小程序端对接Spring Boot后端时最大的坑在跨域和鉴权。如果你是线上测试域名必须配置合法证书否则小程序请求会被拦截如果你是本地开发调试可以用开发者工具的“不校验合法域名”选项临时绕过但这个只能用来开发不能到上线阶段还开着。小程序端的登录有自己的体系建议做法是小程序端调用微信登录获取code后端拿这个code调用微信接口换取openid然后用自己的逻辑创建或关联系统用户再生成JWT返回给小程序。这样才能把小程序用户和系统的用户表打通。4.3 部署上线与文件存储的实操建议到了部署环节很多人才发现开发环境一切正常一到服务器上就各种起不来。最基本的三件事确认服务器装了对应版本的JDK、确认MySQL的字符集是utf8mb4、确认防火墙放行了8080端口。宠物图片的存储开发环境可以直接放到本地磁盘目录比如/var/pet-images给Nginx做一个静态资源映射就可以访问。如果要上云直接用对象存储服务存文件名把访问域名存到数据库里这样代码里基本不用改路径逻辑。Spring Boot项目打包成jar后可以用一行命令启动nohup java -jar pet-adopt-system.jar --server.port8080 app.log 21 日志输出到文件里出问题时直接看日志比看控制台方便得多。我建议所有第一次部署的同学先学会看启动日志中的“Started Application in x seconds”这句话看着它出现再考虑下一步调接口的事。5. 高频踩坑记录与排查速查表长期帮人看这类项目的代码我发现很多问题其实是反复出现的总结成一份备查手册能帮你少走很多弯路。5.1 启动阶段的经典报错端口被占用是最常见的。默认8080端口经常被其他进程抢走报错信息一般是Port 8080 was already in use。解决办法要么换端口启动要么找出占用的进程干掉。数据库连接失败要先分清楚是驱动没加、地址写错、还是权限不对。Spring Boot连接MySQL需要加上mysql-connector-j依赖这就经常有人漏掉。另外如果数据库地址写的是localhost而驱动版本太高也可能报连接错误统一改成127.0.0.1加正确端口一般能解决。Bean创建失败往往是Entity里字段名和数据库列名对不上JPA在启动校验时会直接报错。遇到这个错误别急着怀疑配置先检查实体类的Column(namexxx)。5.2 数据层和时间字段的幺蛾子JPA的LocalDateTime字段有序列化问题返回给前端时默认可能带一段冗长的序列化结果或者格式不符合前端预期。解决办法是在配置里指定全局的日期格式或者给字段加JsonFormat注解。spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8还有一个时区问题很隐蔽服务器默认时区不是东八区的话new Date()插入数据库的时间会比本地晚8个小时。如果你发现入库时间不对先检查MySQL的连接参数里是否加了serverTimezoneAsia/Shanghai。5.3 领养流程里的边界情况处理重复申请的问题是这类系统的高频bug。用户点了一次申请没有反馈又点了一次结果生成两条申请记录。解决办法其实写在了业务代码里在保存前查询“是否存在同宠物同用户的待审核记录”。但这还不算最隐蔽的最隐蔽的是审核通过后宠物的状态没同步更新导致“已领养”的宠物还在列表里展示。这两个问题本质上都是“状态一致性”没处理好。5.4 安全与并发方面的几点提醒安全方面最重要的三件事密码必须加密存储、数据库操作不能用字符串拼接SQL、管理接口必须做角色校验。这三点没做到系统被日穿只是时间问题。并发方面的提醒是如果真遇到多个人同时对同一只宠物提交申请的极端情况可以考虑在申请人提交时锁一下宠物记录或者加个乐观锁字段虽然对于一般规模的毕设项目完全用不上但面试时能答出这个场景会让面试官觉得你真的想过这些问题。5.5 排查问题的推荐顺序后端接口出问题我建议不要盯着代码看用效率更快的排查链条先看接口请求是否到达了后端再查Controller是否正确接收参数接着看Service层的日志、SQL语句最后才是检查数据库数据。一套下来90%的问题都能定位到。前端出问题优先打开浏览器开发者工具的Network面板看接口状态码405就是路径或请求方式不对500就是后端异常401或者403就是登录鉴权出了问题。最后按我的个人习惯给正在做这类项目的朋友一点建议代码能跑只是起点真正值得花时间的是把流程和状态梳理清楚。你可以试着把整个系统的操作日志从用户注册、浏览宠物、提交申请、管理员审核、回访登记串起来在纸上画出每一个状态的变化。这件事做完哪怕是面试的时候被问到“领养审核通过了宠物状态怎么变”你也能不假思索答出来。这比死记硬背一堆面试题靠谱得多。
