1. 宠物猫认养系统到底在解决什么问题1.1 需求背景流浪猫与认养信息不对称做这个项目之前我其实先跑了一圈线下宠物救助站和几家做流浪动物领养的公益组织发现一个很普遍的问题救助站里猫很多但信息基本靠微信群发照片、朋友圈转发表格登记靠Excel认养人提交申请靠私聊管理员审核靠肉眼比对聊天记录。信息一旦多起来谁申请了哪只猫、猫疫苗打没打、绝育做没做、认养人是否符合条件基本理不清。再往深一层看普通用户想认养一只猫唯一的渠道是去救助站实地看或者翻朋友圈转发的图片。没有统一的展示平台猫的照片、性格、健康状况、免疫记录都分散在不同人的手机里。猫送不出去用户找不到猫这件事的本质是信息不对称。SpringBootVue宠物猫认养系统平台就是把这个流程搬到线上管理员后台维护猫咪档案前台用户浏览猫咪列表、查看详情、提交认养申请、跟踪审核结果形成一个完整闭环。1.2 核心业务流程和角色边界一个标准的宠物猫认养系统业务上必须拆清楚两类角色普通用户认养人注册登录后浏览猫咪信息、按品种/年龄/性别筛选、查看猫咪详情、提交认养申请、查看申请进度、收藏猫咪、在平台留言。管理员维护猫咪档案新增、编辑、下架、审核认养申请、管理用户列表、发布公告资讯、处理留言反馈、查看认养数据统计。这套流程背后藏着几条关键业务规则做毕设或者接真实项目时最容易漏同一只猫不能同时被多个用户认养。猫只有待认养状态时才能提交申请一旦申请通过猫状态变为已认养前台不可再申请。认养申请需要审核状态机。常见状态是待审核 → 已通过 / 已驳回通过后猫被标记为已认养。有的系统还会加待家访环节但毕设做到三态就够了。管理员下架猫咪后前台不可见但数据库里要保留记录方便后续统计。这套业务用一句话总结前台展示 申请流转 后台管理。所有功能模块都围绕这三件事展开也是后面设计数据库表和接口文档的地基。2. SpringBootVueMySQL这套组合为什么是毕设标配2.1 后端选型SpringBoot把配置复杂度打下来了很多同学在选后端框架时会在SpringBoot和SSHStrutsSpringHibernate之间纠结甚至有人提Servlet原生开发。我的建议很直接这个项目用SpringBoot没有悬念。理由有三点第一SpringBoot的自动配置机制极大减少了传统SSMSpringSpringMVCMyBatis里的XML配置工作量。传统SSM要配置web.xml、spring-mvc.xml、mybatis-config.xml等一堆文件任何一个小配置写错启动直接报错排查半天可能只是少了依赖。SpringBoot用application.yml一个文件搞定大部分配置对毕设项目来说能用最少的时间跑通项目比炫技式地用最底层技术重要得多。第二市面上的毕设参考代码、教程、社区问答绝大多数都是SpringBoot版本的遇到问题搜得到卡壳频率骤降。第三SpringBoot内嵌Tomcat打包成jar直接运行部署环节简单。这对后面要部署到服务器展示给答辩老师看帮助很大。2.2 前端选型Vue Element UI的组合拳前端框架在Vue2和Vue3之间确实让人犹豫。如果是从零开始学我建议采用你拿到的源码所用的版本如果是自行开发Vue3 Vite Element Plus是当前主流方向。但有一个现实问题Vue3的生态资料虽然已经很多但很多网上的教程、组件库示例还停留在Vue2遇到问题需要自己在Vue3语境下重新理解一遍。考虑到这是毕设项目核心诉求是快速、稳定、够用最终选型的判断标准是你拿到的源码是哪个版本就顺着那个版本走不要中途升级。前端页面用Vue Router做路由跳转、Axios做HTTP请求、Element UI组件库搭建后台管理界面这套组合的好处是组件成熟、交互效果现成不需要自己造轮子。前端整体规划为两个端前台用户端猫咪展示列表、猫咪详情、认养申请表单、个人中心我的申请、我的收藏、公告列表、留言板、登录注册页。后台管理端Dashboard数据概览、猫咪管理表格、认养申请审核列表、用户管理、公告管理、留言管理。2.3 为什么不建议上微服务和Docker这个项目执行过程中我也会收到类似的提问要不要用Spring Cloud拆微服务 要不要用Docker部署我的回答很明确不要。宠物猫认养系统的核心业务复杂度远远用不到微服务。微服务带来的服务注册发现、配置中心、网关、分布式事务等问题每一个都足够让毕设项目卡壳好几天。Docker部署确实干净但前提是你对Dockerfile、镜像构建、容器网络有足够理解否则部署环节出现端口映射问题、数据卷挂载问题反而比直接用jar包运行更复杂。技术选型不是越新越好而是刚好满足业务需求、自己能把控、答辩能讲清楚才是最好。你写在论文里的每个技术名词都得能接住评委老师的追问。3. 数据库设计的核心猫只档案与认养业务的表结构拆解3.1 核心表结构一览数据库设计是整个系统的地基SQL脚本文件里几十张表如果看不懂后面接口开发、前端联调全都会懵。我把核心表整理成一张表先建立整体认知表名用途关键字段user用户表id, username, password(MD5加密), phone, email, role(0用户/1管理员), avatarcat猫咪信息表id, name, breed, age, sex, color, health_status, vaccinated, neutered, description, photo, status(0待认养/1已认养/2下架), create_timeadoption_application认养申请表id, user_id, cat_id, reason, experience, status(0待审核/1通过/2驳回), apply_time, audit_time, audit_remarkfavorite收藏表id, user_id, cat_id, create_timenotice公告表id, title, content, create_timemessage留言表id, user_id, content, reply, create_timecategory猫咪分类表id, name如英短、美短、中华田园猫用户和猫咪的关联关系最核心的就是认养申请表这张中间表。一只猫对应多条申请记录一个用户可以申请多只猫但每只猫最终只有一条已通过的申请记录。这个约束不用在数据库层面用复杂索引去强保证而是在认养审核通过的业务逻辑里加判断查询这只猫是否已有status为1的申请记录有则拒绝新申请。3.2 认养流程的状态流转设计状态机是认养系统的灵魂设计不好后面前后端联调时要反复改。我推荐的流转模型如下用户提交申请 → 申请状态为0(待审核) 管理员同意 → 申请状态改为1(通过)同时cat.status改为1(已认养) 管理员驳回 → 申请状态改为2(驳回)cat.status保持0(待认养)用户可以再次提交一个细节值得注意驳回时需要填写驳回原因。前端表单和后端接口都要预留audit_remark字段否则用户看到申请被驳回却不知道原因会认为是系统故障。另外用户端要限制同一用户对同一只猫只能提交一次申请且申请状态为待审核或已通过时不能重复提交。这个逻辑放在后端Service层判断而非前端隐藏按钮因为接口是可以被直接调用的前端限制只是体验手段。3.3 SQL脚本导入时的两个坑第一个坑是字符集。SQL脚本里CREATE DATABASE语句要明确指定utf8mb4而不是utf8。utf8mb4是utf8的超集能存Emoji表情和生僻字。现在用户昵称、猫咪描述里出现Emoji的概率极高用utf8会直接报Incorrect string value错误。第二个坑是导入顺序。如果你拿到的SQL脚本里有外键约束其实我建议外键在代码层面控制但很多毕设脚本会加物理外键导入时父表必须比子表先导入否则报错。更安全的做法是在每个CREATE TABLE语句前加DROP TABLE IF EXISTS这样反复执行脚本也不会因已存在表而中断。4. 接口文档背后前后端联调的关键路径4.1 RESTful接口设计规范与统一返回体接口文档是前后端开发之间的契约。拿到源码后我建议第一件事不是急着跑起来而是通读接口文档了解后端提供了哪些接口、每个接口的参数和返回结构是什么。这个项目里的接口设计遵循RESTful风格核心接口按资源划分/api/user/login、/api/user/register—— 登录注册/api/cat/list、/api/cat/detail/{id}—— 猫咪列表和详情/api/adoption/apply、/api/adoption/myList—— 提交申请和查看我的申请/api/admin/cat/add、/api/admin/cat/update—— 管理员增改猫咪/api/admin/adoption/audit—— 管理员审核申请/api/notice/list、/api/message/add—— 公告和留言这里必须强调统一返回体设计。如果每个接口返回格式不一样前端解析时会非常痛苦。推荐所有接口统一返回结构{ code: 200, message: 操作成功, data: {} }业务异常返回code为500或自定义错误码message写明错误信息。前端Axios拦截器统一处理code——非200时弹出message无需在每个页面重复写错误处理逻辑。4.2 需要重点关注的五个核心接口通读接口文档后我认为有五个接口是整个系统的核心命脉建议优先跑通并理解1. 登录接口POST /api/user/login。参数为username和password密码传输建议用MD5加密或HTTPS。返回体里包含token和用户信息前端把token存到localStorage后续所有请求在header里携带。2. 猫咪列表接口GET /api/cat/list。支持分页和条件筛选品种、性别、状态返回数据结构是分页对象包含total和records。前端表格或卡片列表直接绑定records。3. 提交认养申请接口POST /api/adoption/apply。参数为catId和reason。后端要做三重校验用户是否登录、猫是否存在且状态为待认养、该用户是否已申请过这只猫。三重校验缺一不可。4. 认养审核接口POST /api/admin/adoption/audit。参数为applicationId、auditStatus、auditRemark。通过时开启事务同时更新申请状态和猫状态。5. 图片上传接口POST /api/upload。用MultipartFile接收文件保存到本地磁盘或OSS/MinIO热词中提到minioMinIO的SpringBoot整合方案成熟适合进阶。返回访问URL存入数据库。4.3 跨域问题和登录状态前端项目单独启动时比如Vue跑在8080端口SpringBoot跑在8081端口前端请求后端必然触发跨域问题。解决办法在SpringBoot添加全局CORS配置类Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); } }登录状态这里有个重要决定用JWT还是SessionSpringBoot默认支持Session但前后端分离场景下更推荐JWTJSON Web Token。登录成功后后端生成token返回前端存localStorage请求时放Authorization头。后端写一个拦截器统一校验token未通过返回401。这样无需在Controller里每个方法判断用户状态代码干净很多。5. 源码结构、环境搭建与本地跑通5.1 项目目录结构拿到源码后别急着双击运行先把目录结构看懂。标准的SpringBootVue前后端分离项目源码包内通常是两个目录pet-adoption/ ├── backend/ # SpringBoot后端 │ ├── src/main/java/com/example/adoption/ │ │ ├── controller/ # 控制层接收请求 │ │ ├── service/ # 业务逻辑层写状态流转判断 │ │ ├── mapper/ # MyBatis持久层接口 │ │ ├── entity/ # 数据库实体类 │ │ ├── config/ # 配置类CORS、拦截器 │ │ └── common/ # 统一返回体、异常处理 │ ├── src/main/resources/ │ │ ├── application.yml # 数据库连接配置 │ │ └── mapper/ # MyBatis XML文件 │ └── pom.xml ├── frontend/ # Vue前端 │ ├── src/ │ │ ├── api/ # Axios请求封装 │ │ ├── router/ # 路由配置 │ │ ├── views/ # 页面组件 │ │ ├── components/ # 公共组件 │ │ └── store/ # 状态管理 │ ├── package.json │ └── vite.config.js / vue.config.js ├── sql/ │ └── pet_adoption.sql # 数据库脚本 └── 接口文档.md这个结构是标准的三层架构前后端分离答辩时讲起来很有条理前端发请求Controller接收Service处理业务Mapper操作数据库。5.2 本地运行步骤第一步装环境。JDK1.8SpringBoot2.x或JDK17SpringBoot3.xMaven3.6Node.js14MySQL5.7/8.0Navicat或IDEA的数据库工具。第二步建库导数据。用Navicat执行SQL脚本确认表都建出来了且自带测试数据。测试数据很重要否则前端页面空荡荡没法演示。第三步改后端配置。打开application.yml把数据库账号密码改成你自己的注意url里的数据库名要对上spring: datasource: url: jdbc:mysql://localhost:3306/pet_adoption?useUnicodetruecharacterEncodingutf8mb4serverTimezoneAsia/Shanghai username: root password: 你的密码第四步启动后端。IDEA打开backend目录等Maven导入依赖直接运行主类。看到Started Application in x seconds就说明启动成功端口默认8080。第五步启动前端。终端cd到frontend目录执行npm install安装依赖然后npm run serve启动开发服务器浏览器访问localhost:8080。5.3 前端打包集成进SpringBoot开发阶段前后端分离跑答辩演示时如果还要开两个终端显得不够利落很多同学会问怎么把Vue打包进SpringBoot里。这是热词里提到的场景做法如下先在frontend目录执行npm run build得到dist目录里面是静态文件index.html、css、js。然后把dist目录里的文件复制到SpringBoot的src/main/resources/static目录下。重新打包运行SpringBoot直接访问http://localhost:8080就是前端页面完全不需要单独启动Vue开发服务器。这里有一个坑必须提醒Vue路由使用history模式时刷新页面会404。因为SpringBoot默认无法处理前端路由的URL。解决办法有三把Vue路由改成hash模式URL带#号不影响演示效果最简单。写一个Controller转发所有非API请求到index.html。配置WebMvcConfigurer的addViewControllers把/**指向index.html。我用过第二种方案配置上也最稳定Controller public class IndexController { RequestMapping(value {/, /index, /cat/**, /user/**, /admin/**}) public String index() { return forward:/index.html; } }5.4 常见环境问题排查表跑通过程中最花时间的通常是环境问题这里列出真实项目中常见的问题及排查方向现象根因排查方向后端启动失败报Cannot determine embedded database driverapplication.yml数据源配置错误检查url、username、passwordSQL脚本导入报错版本兼容/字符集确认MySQL版本、库的字符集为utf8mb4前端npm install卡住网络问题使用国内npm镜像源npm config set registry https://registry.npmmirror.com前端请求报404接口路径对不上用Postman单独测接口确定是前端还是后端问题跨域报错前后端端口不同配置CORS或使用代理vite/server或vue.config.js里配proxy图片上传后刷新图片加载不出来静态资源映射没配置SpringBoot配置addResourceHandlers映射上传目录6. 毕设答辩环节的加分点与避坑事项6.1 答辩时怎么说项目亮点很多同学的答辩稿是照着项目功能列表念的本系统采用了SpringBoot和Vue技术实现了猫咪信息管理、认养申请、后台审核等功能。这种讲法评委一天听十几遍毫无记忆点。换个思路讲设计时的决策过程讲技术选型时可以说我对比过SSH和SpringBootSpringBoot的自动配置减少了我手工搭建环境的时间让我把更多精力放在业务逻辑上——这体现你有思考。讲认养审核时可以说我设计了一个三态状态机并在Service层做了三重校验猫是否可认养、用户是否重复申请、审核通过时事务更新猫状态——这体现你理解了业务本质。讲接口设计时可以说我定义了统一返回体前端Axios统一拦截处理这让我前后端并行开发时没有任何对接歧义——这体现你有工程化意识。6.2 评委常问的几个问题根据我的经验评委对毕设项目的提问集中在几个方向第一个方向数据库设计。这张表的主外键关系是什么 一只猫被多个用户申请后怎么保证不会被重复认养 这类问题要提前理清楚回答核心是通过认养申请表的status字段和事务控制。第二个方向关键技术。SpringBoot自动配置的原理是什么 至少要知道SpringBootApplication是Configuration、EnableAutoConfiguration、ComponentScan三个注解的组合自动配置通过META-INF下的spring.factories加载这类核心概念。第三个方向安全控制。用户密码怎么存储 没有登录能不能访问后台接口 必须回答密码MD5加密建议说BCrypt更安全后台接口由拦截器统一校验JWT不是靠前端隐藏按钮来保护。第四个方向业务流程。如果审核通过了数据库里哪些表哪些字段会变 这个一定要能在数据库里找到对应位置一旦卡壳会非常减分。建议答辩前把所有流程在本地完整跑几遍截图和日志都准备好。6.3 时间规划建议如果我是从零开始复现或二次开发这个项目会按这样的节奏推进第一周搭环境、导库导数据、跑通前后端目标是一天之内看到完整页面。这一周所有精力解决环境问题分析阶段不要动代码。第二周逐模块阅读源码前端的路由表、后端每个Controller对应一张表把请求链路画出来。目标是能看着前端页面说出这个点击背后走了哪些接口查了哪些表。第三周开始动手改功能。比如加一个猫咪健康记录模块或者把文件存储从本地改成MinIO。改的过程就是深度理解的过程。第四周整理接口文档、写论文、准备PPT、制作操作演示视频。把答辩时可能被问到的问题全部写在纸上逐条准备答案。7. 二次开发扩展方向让这个项目更值钱的三条路线跑通源码只是第一步。真正让这个项目和其他毕设拉开差距的是你额外做了哪些增强。我个人实际操作下来有三条性价比最高的扩展路线。第一条是文件存储升级到MinIO。本地磁盘存储的缺点是服务器重启、迁移时图片容易丢而且如果项目部署到云服务器磁盘空间有限。MinIO是开源的对象存储服务支持S3协议整合到SpringBoot非常成熟。改造点集中在配置文件、上传工具类、资源映射三处代码量不大但论文里可以写引入分布式对象存储解决图片持久化问题技术含金量明显提升。第二条是加入消息推送能力。当前系统里用户提交认养申请后管理员必须主动登录后台才能看到。如果能接入简单的消息通知比如申请提交后给管理员发系统通知审核完成后给用户站内信业务闭环就更完整。实现方案不需要引入消息队列一个message表加轮询接口就够但对用户体验的提升是质变的。第三条是数据可视化洞察。后台Dashboard目前可能只是统计总数。可以扩展为猫咪品种分布饼图、认养趋势折线图、审核通过率环形图前端用ECharts组件后端写几个聚合统计接口。这个方向的性价比最高——SQL里用GROUP BY和COUNT组合就能搞定统计逻辑但呈现效果在答辩时非常直观。扩展功能的顺序建议是先做图片存储升级因为涉及数据可靠性再做消息通知涉及业务闭环最后做数据可视化涉及展示效果。每完成一个扩展就在论文中对应功能的测试结果部分补上截图和说明。如果这篇笔记对你跑通这个项目有帮助可以按自己的节奏试试看。我个人建议不要停留在能跑起来就行花点时间把上面提到的事务控制、状态机设计、拦截器逻辑读一遍答辩时你会感谢自己的。
SpringBoot+Vue宠物猫认养系统：从数据库设计到部署答辩全解析
1. 宠物猫认养系统到底在解决什么问题1.1 需求背景流浪猫与认养信息不对称做这个项目之前我其实先跑了一圈线下宠物救助站和几家做流浪动物领养的公益组织发现一个很普遍的问题救助站里猫很多但信息基本靠微信群发照片、朋友圈转发表格登记靠Excel认养人提交申请靠私聊管理员审核靠肉眼比对聊天记录。信息一旦多起来谁申请了哪只猫、猫疫苗打没打、绝育做没做、认养人是否符合条件基本理不清。再往深一层看普通用户想认养一只猫唯一的渠道是去救助站实地看或者翻朋友圈转发的图片。没有统一的展示平台猫的照片、性格、健康状况、免疫记录都分散在不同人的手机里。猫送不出去用户找不到猫这件事的本质是信息不对称。SpringBootVue宠物猫认养系统平台就是把这个流程搬到线上管理员后台维护猫咪档案前台用户浏览猫咪列表、查看详情、提交认养申请、跟踪审核结果形成一个完整闭环。1.2 核心业务流程和角色边界一个标准的宠物猫认养系统业务上必须拆清楚两类角色普通用户认养人注册登录后浏览猫咪信息、按品种/年龄/性别筛选、查看猫咪详情、提交认养申请、查看申请进度、收藏猫咪、在平台留言。管理员维护猫咪档案新增、编辑、下架、审核认养申请、管理用户列表、发布公告资讯、处理留言反馈、查看认养数据统计。这套流程背后藏着几条关键业务规则做毕设或者接真实项目时最容易漏同一只猫不能同时被多个用户认养。猫只有待认养状态时才能提交申请一旦申请通过猫状态变为已认养前台不可再申请。认养申请需要审核状态机。常见状态是待审核 → 已通过 / 已驳回通过后猫被标记为已认养。有的系统还会加待家访环节但毕设做到三态就够了。管理员下架猫咪后前台不可见但数据库里要保留记录方便后续统计。这套业务用一句话总结前台展示 申请流转 后台管理。所有功能模块都围绕这三件事展开也是后面设计数据库表和接口文档的地基。2. SpringBootVueMySQL这套组合为什么是毕设标配2.1 后端选型SpringBoot把配置复杂度打下来了很多同学在选后端框架时会在SpringBoot和SSHStrutsSpringHibernate之间纠结甚至有人提Servlet原生开发。我的建议很直接这个项目用SpringBoot没有悬念。理由有三点第一SpringBoot的自动配置机制极大减少了传统SSMSpringSpringMVCMyBatis里的XML配置工作量。传统SSM要配置web.xml、spring-mvc.xml、mybatis-config.xml等一堆文件任何一个小配置写错启动直接报错排查半天可能只是少了依赖。SpringBoot用application.yml一个文件搞定大部分配置对毕设项目来说能用最少的时间跑通项目比炫技式地用最底层技术重要得多。第二市面上的毕设参考代码、教程、社区问答绝大多数都是SpringBoot版本的遇到问题搜得到卡壳频率骤降。第三SpringBoot内嵌Tomcat打包成jar直接运行部署环节简单。这对后面要部署到服务器展示给答辩老师看帮助很大。2.2 前端选型Vue Element UI的组合拳前端框架在Vue2和Vue3之间确实让人犹豫。如果是从零开始学我建议采用你拿到的源码所用的版本如果是自行开发Vue3 Vite Element Plus是当前主流方向。但有一个现实问题Vue3的生态资料虽然已经很多但很多网上的教程、组件库示例还停留在Vue2遇到问题需要自己在Vue3语境下重新理解一遍。考虑到这是毕设项目核心诉求是快速、稳定、够用最终选型的判断标准是你拿到的源码是哪个版本就顺着那个版本走不要中途升级。前端页面用Vue Router做路由跳转、Axios做HTTP请求、Element UI组件库搭建后台管理界面这套组合的好处是组件成熟、交互效果现成不需要自己造轮子。前端整体规划为两个端前台用户端猫咪展示列表、猫咪详情、认养申请表单、个人中心我的申请、我的收藏、公告列表、留言板、登录注册页。后台管理端Dashboard数据概览、猫咪管理表格、认养申请审核列表、用户管理、公告管理、留言管理。2.3 为什么不建议上微服务和Docker这个项目执行过程中我也会收到类似的提问要不要用Spring Cloud拆微服务 要不要用Docker部署我的回答很明确不要。宠物猫认养系统的核心业务复杂度远远用不到微服务。微服务带来的服务注册发现、配置中心、网关、分布式事务等问题每一个都足够让毕设项目卡壳好几天。Docker部署确实干净但前提是你对Dockerfile、镜像构建、容器网络有足够理解否则部署环节出现端口映射问题、数据卷挂载问题反而比直接用jar包运行更复杂。技术选型不是越新越好而是刚好满足业务需求、自己能把控、答辩能讲清楚才是最好。你写在论文里的每个技术名词都得能接住评委老师的追问。3. 数据库设计的核心猫只档案与认养业务的表结构拆解3.1 核心表结构一览数据库设计是整个系统的地基SQL脚本文件里几十张表如果看不懂后面接口开发、前端联调全都会懵。我把核心表整理成一张表先建立整体认知表名用途关键字段user用户表id, username, password(MD5加密), phone, email, role(0用户/1管理员), avatarcat猫咪信息表id, name, breed, age, sex, color, health_status, vaccinated, neutered, description, photo, status(0待认养/1已认养/2下架), create_timeadoption_application认养申请表id, user_id, cat_id, reason, experience, status(0待审核/1通过/2驳回), apply_time, audit_time, audit_remarkfavorite收藏表id, user_id, cat_id, create_timenotice公告表id, title, content, create_timemessage留言表id, user_id, content, reply, create_timecategory猫咪分类表id, name如英短、美短、中华田园猫用户和猫咪的关联关系最核心的就是认养申请表这张中间表。一只猫对应多条申请记录一个用户可以申请多只猫但每只猫最终只有一条已通过的申请记录。这个约束不用在数据库层面用复杂索引去强保证而是在认养审核通过的业务逻辑里加判断查询这只猫是否已有status为1的申请记录有则拒绝新申请。3.2 认养流程的状态流转设计状态机是认养系统的灵魂设计不好后面前后端联调时要反复改。我推荐的流转模型如下用户提交申请 → 申请状态为0(待审核) 管理员同意 → 申请状态改为1(通过)同时cat.status改为1(已认养) 管理员驳回 → 申请状态改为2(驳回)cat.status保持0(待认养)用户可以再次提交一个细节值得注意驳回时需要填写驳回原因。前端表单和后端接口都要预留audit_remark字段否则用户看到申请被驳回却不知道原因会认为是系统故障。另外用户端要限制同一用户对同一只猫只能提交一次申请且申请状态为待审核或已通过时不能重复提交。这个逻辑放在后端Service层判断而非前端隐藏按钮因为接口是可以被直接调用的前端限制只是体验手段。3.3 SQL脚本导入时的两个坑第一个坑是字符集。SQL脚本里CREATE DATABASE语句要明确指定utf8mb4而不是utf8。utf8mb4是utf8的超集能存Emoji表情和生僻字。现在用户昵称、猫咪描述里出现Emoji的概率极高用utf8会直接报Incorrect string value错误。第二个坑是导入顺序。如果你拿到的SQL脚本里有外键约束其实我建议外键在代码层面控制但很多毕设脚本会加物理外键导入时父表必须比子表先导入否则报错。更安全的做法是在每个CREATE TABLE语句前加DROP TABLE IF EXISTS这样反复执行脚本也不会因已存在表而中断。4. 接口文档背后前后端联调的关键路径4.1 RESTful接口设计规范与统一返回体接口文档是前后端开发之间的契约。拿到源码后我建议第一件事不是急着跑起来而是通读接口文档了解后端提供了哪些接口、每个接口的参数和返回结构是什么。这个项目里的接口设计遵循RESTful风格核心接口按资源划分/api/user/login、/api/user/register—— 登录注册/api/cat/list、/api/cat/detail/{id}—— 猫咪列表和详情/api/adoption/apply、/api/adoption/myList—— 提交申请和查看我的申请/api/admin/cat/add、/api/admin/cat/update—— 管理员增改猫咪/api/admin/adoption/audit—— 管理员审核申请/api/notice/list、/api/message/add—— 公告和留言这里必须强调统一返回体设计。如果每个接口返回格式不一样前端解析时会非常痛苦。推荐所有接口统一返回结构{ code: 200, message: 操作成功, data: {} }业务异常返回code为500或自定义错误码message写明错误信息。前端Axios拦截器统一处理code——非200时弹出message无需在每个页面重复写错误处理逻辑。4.2 需要重点关注的五个核心接口通读接口文档后我认为有五个接口是整个系统的核心命脉建议优先跑通并理解1. 登录接口POST /api/user/login。参数为username和password密码传输建议用MD5加密或HTTPS。返回体里包含token和用户信息前端把token存到localStorage后续所有请求在header里携带。2. 猫咪列表接口GET /api/cat/list。支持分页和条件筛选品种、性别、状态返回数据结构是分页对象包含total和records。前端表格或卡片列表直接绑定records。3. 提交认养申请接口POST /api/adoption/apply。参数为catId和reason。后端要做三重校验用户是否登录、猫是否存在且状态为待认养、该用户是否已申请过这只猫。三重校验缺一不可。4. 认养审核接口POST /api/admin/adoption/audit。参数为applicationId、auditStatus、auditRemark。通过时开启事务同时更新申请状态和猫状态。5. 图片上传接口POST /api/upload。用MultipartFile接收文件保存到本地磁盘或OSS/MinIO热词中提到minioMinIO的SpringBoot整合方案成熟适合进阶。返回访问URL存入数据库。4.3 跨域问题和登录状态前端项目单独启动时比如Vue跑在8080端口SpringBoot跑在8081端口前端请求后端必然触发跨域问题。解决办法在SpringBoot添加全局CORS配置类Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); } }登录状态这里有个重要决定用JWT还是SessionSpringBoot默认支持Session但前后端分离场景下更推荐JWTJSON Web Token。登录成功后后端生成token返回前端存localStorage请求时放Authorization头。后端写一个拦截器统一校验token未通过返回401。这样无需在Controller里每个方法判断用户状态代码干净很多。5. 源码结构、环境搭建与本地跑通5.1 项目目录结构拿到源码后别急着双击运行先把目录结构看懂。标准的SpringBootVue前后端分离项目源码包内通常是两个目录pet-adoption/ ├── backend/ # SpringBoot后端 │ ├── src/main/java/com/example/adoption/ │ │ ├── controller/ # 控制层接收请求 │ │ ├── service/ # 业务逻辑层写状态流转判断 │ │ ├── mapper/ # MyBatis持久层接口 │ │ ├── entity/ # 数据库实体类 │ │ ├── config/ # 配置类CORS、拦截器 │ │ └── common/ # 统一返回体、异常处理 │ ├── src/main/resources/ │ │ ├── application.yml # 数据库连接配置 │ │ └── mapper/ # MyBatis XML文件 │ └── pom.xml ├── frontend/ # Vue前端 │ ├── src/ │ │ ├── api/ # Axios请求封装 │ │ ├── router/ # 路由配置 │ │ ├── views/ # 页面组件 │ │ ├── components/ # 公共组件 │ │ └── store/ # 状态管理 │ ├── package.json │ └── vite.config.js / vue.config.js ├── sql/ │ └── pet_adoption.sql # 数据库脚本 └── 接口文档.md这个结构是标准的三层架构前后端分离答辩时讲起来很有条理前端发请求Controller接收Service处理业务Mapper操作数据库。5.2 本地运行步骤第一步装环境。JDK1.8SpringBoot2.x或JDK17SpringBoot3.xMaven3.6Node.js14MySQL5.7/8.0Navicat或IDEA的数据库工具。第二步建库导数据。用Navicat执行SQL脚本确认表都建出来了且自带测试数据。测试数据很重要否则前端页面空荡荡没法演示。第三步改后端配置。打开application.yml把数据库账号密码改成你自己的注意url里的数据库名要对上spring: datasource: url: jdbc:mysql://localhost:3306/pet_adoption?useUnicodetruecharacterEncodingutf8mb4serverTimezoneAsia/Shanghai username: root password: 你的密码第四步启动后端。IDEA打开backend目录等Maven导入依赖直接运行主类。看到Started Application in x seconds就说明启动成功端口默认8080。第五步启动前端。终端cd到frontend目录执行npm install安装依赖然后npm run serve启动开发服务器浏览器访问localhost:8080。5.3 前端打包集成进SpringBoot开发阶段前后端分离跑答辩演示时如果还要开两个终端显得不够利落很多同学会问怎么把Vue打包进SpringBoot里。这是热词里提到的场景做法如下先在frontend目录执行npm run build得到dist目录里面是静态文件index.html、css、js。然后把dist目录里的文件复制到SpringBoot的src/main/resources/static目录下。重新打包运行SpringBoot直接访问http://localhost:8080就是前端页面完全不需要单独启动Vue开发服务器。这里有一个坑必须提醒Vue路由使用history模式时刷新页面会404。因为SpringBoot默认无法处理前端路由的URL。解决办法有三把Vue路由改成hash模式URL带#号不影响演示效果最简单。写一个Controller转发所有非API请求到index.html。配置WebMvcConfigurer的addViewControllers把/**指向index.html。我用过第二种方案配置上也最稳定Controller public class IndexController { RequestMapping(value {/, /index, /cat/**, /user/**, /admin/**}) public String index() { return forward:/index.html; } }5.4 常见环境问题排查表跑通过程中最花时间的通常是环境问题这里列出真实项目中常见的问题及排查方向现象根因排查方向后端启动失败报Cannot determine embedded database driverapplication.yml数据源配置错误检查url、username、passwordSQL脚本导入报错版本兼容/字符集确认MySQL版本、库的字符集为utf8mb4前端npm install卡住网络问题使用国内npm镜像源npm config set registry https://registry.npmmirror.com前端请求报404接口路径对不上用Postman单独测接口确定是前端还是后端问题跨域报错前后端端口不同配置CORS或使用代理vite/server或vue.config.js里配proxy图片上传后刷新图片加载不出来静态资源映射没配置SpringBoot配置addResourceHandlers映射上传目录6. 毕设答辩环节的加分点与避坑事项6.1 答辩时怎么说项目亮点很多同学的答辩稿是照着项目功能列表念的本系统采用了SpringBoot和Vue技术实现了猫咪信息管理、认养申请、后台审核等功能。这种讲法评委一天听十几遍毫无记忆点。换个思路讲设计时的决策过程讲技术选型时可以说我对比过SSH和SpringBootSpringBoot的自动配置减少了我手工搭建环境的时间让我把更多精力放在业务逻辑上——这体现你有思考。讲认养审核时可以说我设计了一个三态状态机并在Service层做了三重校验猫是否可认养、用户是否重复申请、审核通过时事务更新猫状态——这体现你理解了业务本质。讲接口设计时可以说我定义了统一返回体前端Axios统一拦截处理这让我前后端并行开发时没有任何对接歧义——这体现你有工程化意识。6.2 评委常问的几个问题根据我的经验评委对毕设项目的提问集中在几个方向第一个方向数据库设计。这张表的主外键关系是什么 一只猫被多个用户申请后怎么保证不会被重复认养 这类问题要提前理清楚回答核心是通过认养申请表的status字段和事务控制。第二个方向关键技术。SpringBoot自动配置的原理是什么 至少要知道SpringBootApplication是Configuration、EnableAutoConfiguration、ComponentScan三个注解的组合自动配置通过META-INF下的spring.factories加载这类核心概念。第三个方向安全控制。用户密码怎么存储 没有登录能不能访问后台接口 必须回答密码MD5加密建议说BCrypt更安全后台接口由拦截器统一校验JWT不是靠前端隐藏按钮来保护。第四个方向业务流程。如果审核通过了数据库里哪些表哪些字段会变 这个一定要能在数据库里找到对应位置一旦卡壳会非常减分。建议答辩前把所有流程在本地完整跑几遍截图和日志都准备好。6.3 时间规划建议如果我是从零开始复现或二次开发这个项目会按这样的节奏推进第一周搭环境、导库导数据、跑通前后端目标是一天之内看到完整页面。这一周所有精力解决环境问题分析阶段不要动代码。第二周逐模块阅读源码前端的路由表、后端每个Controller对应一张表把请求链路画出来。目标是能看着前端页面说出这个点击背后走了哪些接口查了哪些表。第三周开始动手改功能。比如加一个猫咪健康记录模块或者把文件存储从本地改成MinIO。改的过程就是深度理解的过程。第四周整理接口文档、写论文、准备PPT、制作操作演示视频。把答辩时可能被问到的问题全部写在纸上逐条准备答案。7. 二次开发扩展方向让这个项目更值钱的三条路线跑通源码只是第一步。真正让这个项目和其他毕设拉开差距的是你额外做了哪些增强。我个人实际操作下来有三条性价比最高的扩展路线。第一条是文件存储升级到MinIO。本地磁盘存储的缺点是服务器重启、迁移时图片容易丢而且如果项目部署到云服务器磁盘空间有限。MinIO是开源的对象存储服务支持S3协议整合到SpringBoot非常成熟。改造点集中在配置文件、上传工具类、资源映射三处代码量不大但论文里可以写引入分布式对象存储解决图片持久化问题技术含金量明显提升。第二条是加入消息推送能力。当前系统里用户提交认养申请后管理员必须主动登录后台才能看到。如果能接入简单的消息通知比如申请提交后给管理员发系统通知审核完成后给用户站内信业务闭环就更完整。实现方案不需要引入消息队列一个message表加轮询接口就够但对用户体验的提升是质变的。第三条是数据可视化洞察。后台Dashboard目前可能只是统计总数。可以扩展为猫咪品种分布饼图、认养趋势折线图、审核通过率环形图前端用ECharts组件后端写几个聚合统计接口。这个方向的性价比最高——SQL里用GROUP BY和COUNT组合就能搞定统计逻辑但呈现效果在答辩时非常直观。扩展功能的顺序建议是先做图片存储升级因为涉及数据可靠性再做消息通知涉及业务闭环最后做数据可视化涉及展示效果。每完成一个扩展就在论文中对应功能的测试结果部分补上截图和说明。如果这篇笔记对你跑通这个项目有帮助可以按自己的节奏试试看。我个人建议不要停留在能跑起来就行花点时间把上面提到的事务控制、状态机设计、拦截器逻辑读一遍答辩时你会感谢自己的。
