SpringBoot+Vue宠物领养系统毕设全解析：从表设计到部署上线

又到了一年一度毕设选题的季节后台收到好几个同学问同一个问题想做Java方向的毕设但又不想做烂大街的图书管理系统、学生管理系统有没有既能体现技术栈能力、又有社会价值和创新点的题目我给的答复一直很一致可以考虑做一个基于SpringBootVue的宠物领养系统。为什么推荐这个题先说结论宠物领养系统的业务链路足够完整能覆盖用户注册登录、宠物信息管理、领养申请、审核流转、回访记录、公告发布这些模块天然适合前后端分离架构。更关键的是流浪动物救助匹配这个点能做出一套有逻辑深度的推荐匹配规则这在答辩时是一个非常能打的创新点。这篇内容我尽量把整个系统从选题理由、表设计、匹配算法到部署上线的完整链路讲透只要你能跟着搭完不管是用作毕设还是自己想做点公益相关的项目都能直接落地。1. 为什么是宠物领养这个题目选题价值与真实需求拆解1.1 流浪动物救助站的信息断层这个题目解决的现实问题很多同学选毕设题目的时候习惯从技术好实现这个角度出发但忽略了更重要的一个问题你做的系统到底解决了什么现实场景。宠物领养系统背后的真实场景其实是救助站、宠物医院、大学校园里普遍存在的信息断层。我见过不少校园里的流浪猫救助组织它们的日常是志愿者在微信群发一条宠物照片配上几句手打的文字描述然后靠群里的人接力转发。领养人看到了私聊志愿者聊几天觉得合适约个时间线下看猫合适就带走。看着好像能跑通但实际上一旦宠物数量多起来问题就全暴露了哪只猫打过疫苗、哪只狗还需要复查、这个领养人以前有没有领养记录、送的猫粮是什么牌子容易过敏——所有信息都散落在不同人的聊天记录和Excel表格里根本没法追溯。宠物领养系统要做的就是把这些分散的信息收拢到一个平台里。流浪动物救助匹配平台这个概念核心不只是发帖—申请这种简单的信息发布逻辑而是要把救助站最关心的三件事做成线上流程宠物档案可查、领养申请可审、领养后回访可追。这一个业务闭环恰好能撑起一个结构完整的毕设系统而且每一环都有对应的技术落点。1.2 从毕设评分角度反推哪些功能模块最容易拿分以我接触过的不少Java方向毕设答辩情况来看评分维度通常稳定在四块功能完整度、技术难度、创新点、文档与代码规范。宠物领养系统在这四块上分别能拿到什么分我拆开说一下。功能完整度上这个题目天然具备用户端管理端双向结构。用户端有宠物列表浏览、宠物详情、领养申请提交、个人中心、申请进度查看管理端有宠物档案管理、领养审核、用户管理、回访管理、公告管理。就这一套已经算是一个模块非常完整的单体前后端分离项目了比那种只有一个CRUD的题目厚实得多。技术难度上SpringBoot Vue 本身就是当前Java方向毕设的主流组合但难点通常藏在细节里比如文件上传的静态资源映射、登录鉴权的Token方案、领养申请的状态流转控制、以及后面会细讲到的匹配推荐算法。这些点做好了在答辩现场是实打实的技术加分项。创新点上这是这个题目最占便宜的地方。普通的管理系统哪里有什么创新无非是数据增删改查换个壳。但宠物领养系统里加了救助匹配这个业务概念后整个高度就不同了——你可以根据宠物特征和领养人偏好做一个推荐匹配这部分完全可以写成论文里的系统创新点。文档与代码规范上因为这个系统模块多、表关系清晰ER图、用例图、流程图都有东西可以画写开题报告和论文的时候材料非常充足。1.3 同类系统里常见的画蛇添足与正确取舍做毕设最容易翻车的地方不是功能不够而是功能过多。我见过不少人为了显得系统高大上硬往里塞商城模块、秒杀模块、论坛模块结果论文写得痛苦答辩被追问得更痛苦。宠物领养系统要守住边界。哪些模块不建议加第一在线支付。领养本身大部分是公益性质最多涉及押金或疫苗费用引入支付会带来很大的安全合规复杂度毕设阶段完全没必要碰。第二即时聊天。用户和救助站之间的沟通用站内消息或者公告联系电话就能解决不要去碰WebSocket聊天那不是这个系统的核心。第三社交动态流。容易把系统做成一锅乱炖冲淡领养这个主线。反过来有哪些东西值得保留领养回访记录就非常值得做。一只宠物被人领养走并不是故事的结束救助站通常要求定期回访了解宠物在新家的状况。这个环节做一个回访任务提醒的功能不仅业务上说得通技术上还能用定时任务解决论文素材又多一项。后面我会详细讲怎么用SpringBoot的Scheduled实现回访提醒。2. SpringBootVue的前后端分离设计从用例图到API契约2.1 三种角色三种权限角色权限体系怎么设计才不玩具很多毕设系统的权限设计就一句话管理员能进后台用户不能。这个在答辩时其实很脆弱评委只要追问一句你后台里哪些操作是普通用户可以做的就容易卡壳。宠物领养系统的现实业务里角色应该拆成三个普通用户领养申请人、救助站管理员负责审核和宠物管理、系统管理员负责用户和数据的全局管理。角色权限矩阵我建议按这个来设计功能模块普通用户救助站管理员系统管理员浏览宠物列表/详情允许允许允许提交领养申请允许不允许不允许宠物档案新增/编辑不允许允许不允许领养申请审核不允许允许不允许回访记录管理不允许允许允许用户账号管理不允许不允许允许公告发布不允许允许允许这个矩阵背后的逻辑是贴近真实救助站运营的救助站管理员是系统里最忙的角色他们在线下负责救助动物在线上负责维护宠物档案和处理领养申请。系统管理员则更偏运维性质不需要参与日常业务。普通用户的权限边界很清楚——只能看、只能申请不能修改宠物数据这样就能挡住用户篡改宠物信息这类数据安全风险。技术实现上SpringBoot里我建议用拦截器HandlerInterceptor配合自定义注解来实现接口粒度的权限控制把角色校验从业务代码里抽出来而不是在每个Controller里写if判断。注解名可以叫RequireRole取值是USER、ADMIN之类的角色标识。这样代码清爽答辩讲起来也更有架构感。2.2 核心数据表宠物档案、领养申请、回访记录的字段设计表设计是毕设系统里最能体现基本功的地方。宠物领养系统的核心表我认为至少是这四张用户表、宠物表、领养申请表、回访记录表外加一张公告表做辅助。先看用户表。除了常规的用户名、密码、手机号、邮箱之外要特别注意加一组偏好字段这是后面做匹配推荐的数据基础。比如偏好宠物类型猫/狗、可接受的宠物体型、是否有养宠经验、家庭空间大小、空闲时间。这些字段在设计用户表的时候就预留好否则后面做推荐匹配的时候你会发现数据模型不支持非常被动。宠物表要记录的关键信息更多宠物名称、种类猫/狗/其他、品种、年龄、性别、是否绝育、是否驱虫、疫苗情况、性格描述、救助站编号、健康状态、照片URL、状态。这里的状态非常关键我建议用枚举待领养、审核中已被申请、已领养、已下架。每一次申请提交宠物的状态流转都要和领养申请表联动后面会讲状态机。领养申请表是这个系统的订单中心。字段包括申请编号、用户ID、宠物ID、申请时间、申请状态待审核/已通过/已拒绝/已完成、申请理由、居住情况说明、养宠经验说明。这里要记住一张表承担的是业务流转职责而不是简单的记录。回访记录表相对独立回访编号、领养申请编号、回访时间、回访方式线上/上门、宠物当前状况、回访人意见。这张表的价值在业务闭环上能体现出系统对领养不是一时冲动这个公益理念的支撑。2.3 API契约先行把这些接口定了再写前端前后端分离项目里最大的灾难往往是前后端各写各的最后联调时接口对不上。所以我在这个项目里提倡API契约先行——先把接口路径、请求方法、请求参数、响应结构都定义清楚再开始写代码。接口风格采用RESTful统一响应结构是{ code: 200, message: success, data: {} }几个核心接口清单如下方法路径说明POST/api/user/register用户注册POST/api/user/login登录返回JWTGET/api/pet/list宠物列表支持关键字和筛选参数GET/api/pet/detail/{id}宠物详情POST/api/adoption/apply提交领养申请GET/api/adoption/my我的申请列表GET/api/adoption/pending管理端待审核列表PUT/api/adoption/audit/{id}审核通过/拒绝POST/api/visit/record新增回访记录POST/api/pet/add新增宠物档案这套API设计遵循一个原则能表达做什么而不只是操作什么数据。比如领养申请审核接口用PUT /api/adoption/audit/{id}而不是POST /api/adoption/update因为前者在语义上更清晰答辩时也没人会用你这个是Restful风格吗来纠结了。3. 流浪动物救助匹配到底怎么做推荐逻辑的三种实现方案3.1 方案一基于标签的匹配最推荐毕设用流浪动物救助匹配平台这个关键词是整个题目里最值得深入挖掘的技术点。怎么理解这里说的匹配对于一个领养人来说不是任何一只流浪宠物都适合带走。有人住单身公寓没阳台那就不太适合领养一只精力旺盛的大型犬有人第一次养宠物那最好从性情温顺、已经完成基础疫苗的成年猫入手有人家里已经有原住民宠物那新来的宠物性格是否合群就很重要。基于标签的匹配就是把这套线下经验转化成可计算的规则。实现思路是给每只宠物打上预设标签比如温顺粘人适合新手已绝育已驱虫亲人活泼等用户在个人资料里或者申请时选择自己偏好的标签系统计算宠物标签与用户偏好标签的重合度。具体计算可以这样宠物标签集合记为P用户偏好标签集合记为U匹配度 |P ∩ U| / |U|。这样算出来的值在0到1之间。例如宠物打了4个标签用户偏好中命中了3个匹配度就是0.75。有个地方要格外提醒分母不能用宠物标签总数必须用用户偏好标签总数。原因很简单如果用户只选了2个偏好且都命中匹配度是100%如果用宠物标签数做分母可能一只标签多的宠物永远算不出高匹配度这不合理。3.2 方案二地理位置优先涉及坐标计算救助站和领养人之间的地理距离在线下场景里是一个非常现实的问题。一只在上海的流浪猫被一个在北京的用户申请领养这里面包含的舟车劳顿和宠物运输压力远大于大多数人的想象。所以地理位置可以作为匹配推荐的第二维度。实现上有两种做法。简单做法是用户和救助站都存一个城市字段匹配时只比较城市是否相同这个过滤逻辑最简单但比较粗糙。进阶做法是存经纬度坐标然后通过Haversine公式计算两个坐标点之间的距离private double getDistance(double lat1, double lon1, double lat2, double lon2) { double R 6371.0; // 地球半径单位公里 double radLat1 Math.toRadians(lat1); double radLat2 Math.toRadians(lat2); double dLat Math.toRadians(lat2 - lat1); double dLon Math.toRadians(lon2 - lon1); double a Math.sin(dLat / 2) * Math.sin(dLat / 2) Math.cos(radLat1) * Math.cos(radLat2) * Math.sin(dLon / 2) * Math.sin(dLon / 2); double c 2 * Math.atan2(Math.sqrt(a), Math.sqrt(1 - a)); return R * c; }距离值出来后同样做归一化处理比如规定50公里以内距离得分为1超过200公里得分为0中间线性递减。这个方案的优势是业务说服力很强答辩时简直是被追问的加分项缺点是用户端需要授权获取位置信息或者至少要允许用户填写城市和区域从纯技术角度会略增加前端工作量。3.3 方案三申请行为权重评分体现更懂用户的进阶版如果觉得标签匹配和距离匹配还不够有深度可以在它们的基础上叠加一层行为权重。用户浏览过哪些宠物详情页、收藏过哪些宠物、对哪些宠物发起了申请这些行为信息其实非常有价值。它们不是用户说的偏好而是用户用行为投票表达出的真实偏好。做法是用户每浏览一只宠物详情页就给对应的宠物标签计数加1收藏加3提交领养申请加5。然后定期或实时汇总用户的标签偏好权重。这个方案的好处是完全动态能根据用户的行为不断校正推荐结果坏处是数据累积需要时间而且如果用户行为稀疏计算出的权重偏差会很大。3.4 我的实际选择与参数设定作为毕设项目我的建议是方案一为主方案二为辅方案三作为扩展点写在论文里。推荐列表的排序公式可以定为recommendScore 0.7 * labelMatchScore 0.3 * distanceScore这个权重比例不是拍脑袋定的它背后是一个业务判断在流浪动物领养场景里宠物是否适合这个人是第一位的距离是第二位的。而且0.7和0.3这个比例好解释答辩时一句话就能说清楚为什么不是五五开——因为性格不合的宠物领养回去很容易造成二次弃养这是流浪动物救助组织最害怕的事。技术上这个匹配计算可以做成一个Service里的方法宠物列表查询完成后在Java内存里做排序数据量不大时性能完全够。如果真想做得工程化一点可以引入Redis做评分缓存但毕设阶段没必要反而增加了答辩时被追问缓存一致性的风险。4. 前后端核心代码实现的落地细节4.1 后端宠物档案发布与领养申请状态机后端代码这块很多同学喜欢把业务逻辑全写在Controller里一个方法几百行感觉很省事但答辩一被追问就露怯。我建议至少把Service层做厚。先看宠物档案发布。Controller只做参数接收和结果返回业务逻辑下沉到Service。伪代码逻辑链是接收前端传来的宠物表单数据包括照片文件→ 把照片保存到服务器磁盘并生成访问URL → 构建Pet对象并写入数据库 → 返回宠物ID和详情。重点在于照片保存我用本地磁盘存储路径规范如下Override public Pet addPet(PetDTO petDTO, MultipartFile file) throws IOException { // 1. 判断文件类型只允许jpg/png/jpeg/webp String originalFilename file.getOriginalFilename(); String ext originalFilename.substring(originalFilename.lastIndexOf(.)); if (!ALLOWED_EXTENSIONS.contains(ext.toLowerCase())) { throw new BusinessException(图片格式不支持); } // 2. 生成唯一文件名防止重名覆盖 String newFileName UUID.randomUUID().toString().replace(-, ) ext; // 3. 按日期分目录存储避免单个目录文件过多 String datePath LocalDate.now().format(DateTimeFormatter.ofPattern(yyyy/MM/dd)); File dir new File(UPLOAD_DIR datePath); if (!dir.exists()) { dir.mkdirs(); } // 4. 保存文件并构建访问路径 file.transferTo(new File(dir, newFileName)); String fileUrl /files/ datePath / newFileName; // 5. 落库 Pet pet new Pet(); BeanUtils.copyProperties(petDTO, pet); pet.setPhotoUrl(fileUrl); pet.setStatus(PetStatus.AVAILABLE); return petMapper.insert(pet); }领养申请的状态流转是另一个容易出乱子的地方。一只宠物刚被一个用户申请如果状态还停留在待领养那么另一个用户在同一时间也能申请同一只宠物这样就会产生一猫多主的冲突。解决办法是状态机加数据库约束双保险。状态机在代码里用一个枚举维护public enum AdoptionStatus { PENDING(0, 待审核), APPROVED(1, 已通过), REJECTED(2, 已拒绝), COMPLETED(3, 已完成), CANCELLED(4, 已撤销); }提交申请时Service层先做幂等校验查一下这只宠物当前状态是否是AVAILABLE再用数据库唯一索引兜底pet_id applicant_id做联合唯一索引防止同一用户重复申请同一只宠物。这两个校验都能通过才允许把宠物状态改为审核中并插入申请表。4.2 后端文件上传与静态资源映射的坑文件上传我上面已经写了核心逻辑这里专门说一下SpringBoot里对应的静态资源映射配置。如果你把文件保存到了本地磁盘但访问URL返回404排查方向一定是资源映射没配。要在配置类里加入Configuration public class WebMvcConfig implements WebMvcConfigurer { Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/files/**) .addResourceLocations(file: FILE_UPLOAD_DIR /); } }这个坑我印象特别深因为保存文件和访问文件用的是两套路径逻辑一旦配置写错或者路径末尾少了斜杠前端的宠物图片就是一片空白。另外还有一个编码上的坑如果文件名里带中文访问URL需要做URL编码最好的规避方法就是像我那样用UUID重命名彻底绕开中文文件名问题。4.3 前端Vue路由守卫与axios拦截器的登录控制前端Vue这块登录状态控制的代码虽然不复杂但设计思路是关键。我用的是JWT方案用户登录成功后后端返回一个Token前端存在localStorage里之后每个请求在请求头里带上Authorization字段。路由守卫的作用是页面级别的登录控制。它是Vue Router提供的一个钩子在每次路由跳转前执行router.beforeEach((to, from, next) { const token localStorage.getItem(token); if (to.meta.requiresAuth !token) { next({ path: /login, query: { redirect: to.fullPath } }); } else { next(); } })这里把需要登录才能访问的页面路由都打上meta.requiresAuth标记。你可能会想如果别人知道接口地址不经过前端直接调接口怎么办那就需要axios拦截器做第二层控制。axios拦截器统一在发出请求前添加Token同时对返回的响应做统一错误处理service.interceptors.request.use(config { const token localStorage.getItem(token); if (token) { config.headers.Authorization Bearer ${token}; } return config; }); service.interceptors.response.use( response { const res response.data; if (res.code ! 200) { if (res.code 401) { localStorage.removeItem(token); router.push(/login); } return Promise.reject(new Error(res.message)); } return res; }, error { return Promise.reject(error); } );这套拦截器逻辑的好处是后端接口的鉴权逻辑只要写一遍所有前端请求自动带上凭证登录过期时也会被统一弹回登录页不需要在每个页面手写判断。4.4 前端宠物卡片组件与领养申请表单一个能撑起平台感的前端宠物卡片组件和申请表单是必须要写好的两个组件。宠物卡片组件我用Vue的单文件组件实现接收宠物对象作为props。卡片上展示照片、名称、品种标签、性别、年龄和状态标签。核心思路是卡片组件本身不关心数据从哪来只负责展示和派发事件。比如点击申请领养按钮组件内部emit一个事件由父组件弹窗或跳转去处理。这样宠物列表页、推荐页、搜索页都可以复用同一个组件。领养申请表单要做的是把决策权交给表单它应该引导用户填写有助于救助站审核的信息。字段至少包括居住环境租房/自有、是否有其他宠物、家庭平均在家人数、领养理由。前端用Element UI的Form组件做校验比如领养理由必填而且长度不得少于20字这个校验规则不是为了难为用户而是为了筛掉那些一时冲动的申请顺便还能在答辩里说一句系统通过表单规则设计降低宠物被二次弃养的风险。5. 我从本地到服务器的真实部署经历5.1 打包过程SpringBoot的jar包与Vue的dist目录到部署环节很多人拿着项目在本地上跑得好好的一上服务器就各种404、白屏。这里我建议先把部署流程想清楚前端打包后是一堆静态文件后端打包后是一个可执行的jar包两者需要协同工作。后端打包用的是Maven在项目根目录执行mvn clean package生成target目录下的jar文件。启动命令是java -jar pet-adoption-system.jar --spring.profiles.activeprod我习惯在application-prod.yml里维护生产环境配置数据库地址、文件上传目录、JWT密钥都放在这个配置文件里和开发环境的application-dev.yml隔离开避免本地调试时误连生产库。前端打包用的是npm run build产物是dist目录里面包含index.html、static等静态资源。然后把dist目录上传到服务器的Nginx静态目录里。5.2 Nginx反向代理配置解决前端访问后端的跨域我强烈建议在部署层面就用Nginx解决跨域问题而不是在前端代码里开代理。原因很简单开发环境用Vite代理是为了一时方便生产环境如果前端直接请求后端API地址浏览器会因为跨域拦截掉请求非常难受。在服务器上我的Nginx配置长这样server { listen 80; server_name your-domain.com; # 前端静态资源 location / { root /opt/pet-adoption/dist; index index.html; try_files $uri $uri/ /index.html; } # 后端API反向代理 location /api/ { proxy_pass http://127.0.0.1:8080/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } # 上传图片的访问 location /files/ { proxy_pass http://127.0.0.1:8080/files/; } }配置里有两个非常容易踩的坑。第一个是location /的try_files必须带上回退到index.html的规则。因为你用的是Vue Router的history模式如果不加try_files、而用户直接访问某个子路由比如刷新了一下/pet/3这个页面Nginx会拿着这个路径去找对应的静态文件找不到就报404。第二个是proxy_pass末尾的斜杠location /api/和proxy_pass http://127.0.0.1:8080/组合时/api/login会被转发成/login如果末尾不写斜杠就会变成/api/login直接转发到后端后端接口没这个路径就404了。5.3 数据库初始化脚本与模拟数据数据库这块很多人就是建几张表就结束了但我建议做两件事一是写一个完整的初始化SQL脚本包括建库、建表、插入基础数据二是在脚本里塞一批贴近真实的模拟数据方便开发时调试和答辩时现场演示。初始化脚本的建表顺序要严格注意先建用户表再建宠物表外键引用救助站用户然后是领养申请表外键引用用户表和宠物表最后是回访记录表。顺序反了会导致外键约束报错。模拟数据这部分我建议宠物表插8到12条每只宠物都要有真实的品种、年龄、疫苗情况和性格描述不要用一个cat字段应付。用户插入20到30个其中一部分用户填了偏好标签方便展示匹配推荐效果。我见过有人答辩现场演示时因为模拟数据太少推荐列表全是空的非常尴尬。5.4 最容易忘记的安全清单作为毕设项目不需要做到企业级安全标准但最基本的几件事必须做否则答辩评委随便试几下就能发现漏洞。第一密码不能明文存储必须用BCrypt哈希。Spring Security Crypto里自带BCryptPasswordEncoder用法非常简单但就是有人图省事直接存明文。第二JWT密钥不要硬编码在代码里更不要提交到Git仓库。放到配置文件里用环境变量注入jwt: secret: ${JWT_SECRET:default-dev-secret-key}第三上传文件要做类型白名单校验。我上面的代码里已经写了只允许jpg、png、jpeg、webp这几种格式。这里我再补充一个细节不要只看前端传过来的Content-Type要用MultipartFile对象的getOriginalFilename()去取后缀再结合文件头去判断真实类型否则攻击者可以伪造Content-Type上传恶意文件。第四所有SQL操作必须用参数化查询。MyBatis的#{}语法天然防SQL注入但有人喜欢用${}拼接排序字段或者表名这就要注意了${}是不做预编译的千万不能让用户输入的内容走${}。6. 毕设答辩时最容易被追问的三个方向6.1 你的匹配算法实现原理是什么这个问题可以说是必问的。只要你的系统标题里带了匹配平台三个字评委就会盯上这个点。回答思路要分成三层先讲业务背景再讲数据基础最后讲计算公式。业务背景一定要落到降低二次弃养率上。流浪动物被领养后又被退回甚至遗弃核心原因就是领养人和宠物不匹配所以平台的价值在于让合适的人找到合适的宠物。数据基础是宠物标签和用户偏好标签两个维度。计算公式就是把匹配度公式、距离公式和加权求和公式写在答辩PPT里让评委看到你的推荐逻辑是有数学依据的不是随便排序。最容易被追问的细节是权重为什么是0.7和0.3。我的建议回答是如果匹配度权重过低可能会出现推荐列表里全是距离近但不适合用户的宠物违背了降低弃养率的初衷。这个权重可以通过后续的用户行为反馈数据去做调整比如用户点击率高但领养完成率低的标签组合说明推荐逻辑有偏差这时候要调整。6.2 领养审核流程怎么保证不流于形式这个问题表面上问流程实际上问的是你系统的业务深度。我的回答路径是领养审核不是一个简单的通过/拒绝按钮而是有状态流转和数据佐证的系统过程。支撑这个回答的核心是三块第一宠物状态和申请状态是联动的一只宠物被申请后其他人就不能再申请了避免重复领养第二领养申请表上有详细的问卷字段包括居住环境、养宠经验、家人同意情况这些字段会推送给管理员作为审批参考第三领养成功后系统会生成定期回访任务管理员需要填写回访记录这就形成了申请—审核—领养—回访的完整闭环。如果评委继续追问回访任务怎么触发就可以顺理成章引出定时任务。在SpringBoot中用一个Scheduled注解每隔一段时间扫描所有已完成的领养记录找出距离上次回访超过30天的自动生成一条待办回访记录并给对应管理员发送站内通知。这段代码量不大但体现的工程意识很足。6.3 并发申请下怎么办这个系统的数据安全怎么保证这个问题的答案是乐观锁思路 数据库唯一约束的组合。以宠物领养系统中两个人同时申请同一只宠物的场景来说如果代码里只做Service层的状态判断高并发下会有竞态条件问题。两个用户同时读到宠物状态为AVAILABLE同时判断可以申请然后同时执行插入就会产生脏数据。正确做法有两道防线。防线一数据库层面用乐观锁在宠物表加一个version字段更新时用update pet set statusPENDING, versionversion1 where id1 and versionoldVersion影响行数为0就说明数据已被别人改过当前申请失败。防线二申请表上建立普通用户ID和宠物ID的联合唯一索引保证同一个用户不能重复申请同一只宠物。数据安全部分主要回答上面提到的BCrypt密码加密、JWT鉴权、上传文件白名单、SQL参数化。这四点回答完基本就覆盖了评委关心的几个主要风险点。6.4 有精力的话这些扩展点也可以写进论文如果你的论文需要一点未来展望的素材可以考虑这几个方向但注意不要真的在毕设阶段实现写了反而增加答辩风险。一是引入Elasticsearch做宠物搜索解决宠物特征模糊搜索和标签组合查询的性能问题。二是引入Redis缓存热点宠物信息和推荐列表降低数据库压力。三是把图片存储从本地磁盘换成MinIO做对象存储。这三个方向都是Java后端生态里常见的进阶方案写论文时作为系统未来的优化方向比较自然。我自己的体会是这个题目在毕设里属于看起来不复杂、但真正深入做进去处处有内容的类型。难度上限完全取决于你想做到哪一层基础版能跑通CRUD和领养流程进阶版能做出匹配推荐和回访闭环再往上还能做缓存和检索优化。无论做到哪一层至少比那些千篇一律的增删改查系统要耐看得多也能让评委觉得你是真的理解了一个真实业务场景并把它工程化落地了。如果你正在做这个方向的毕设从表设计开始动手之前一定先把第2章的API契约和第3章的匹配规则想清楚后面写代码会顺很多。祝顺利。