毕业设计这个节点上很多人都绕不开一套“前后端分离”的项目。尤其是宠物服务平台这类选题业务直观、模块清晰、技术栈也常见算得上是一套几乎不会出错的模板。但问题也出在这里源码拿到手真正能讲清楚、能部署、能改业务的人十个里面往往不到一半。这篇就想把这些年基于SpringBootVue做这一类系统的经验和踩过的坑一起理一理从业务边界、工程结构到部署上线和答辩准备一次性说透。1. 这一选题为什么经久不衰从需求到技术栈的闭环1.1 宠物服务平台的业务边界很多同学拿到标题后第一反应是找代码这其实反了。真正应该先想清楚的是宠物服务平台到底要解决什么问题。这决定了你后续改代码、加功能、画架构图时心里有没有底。从业务上看宠物服务平台通常在三件事上做文章信息撮合、服务预约、商品交易。信息撮合包括宠物领养、寻宠启事、宠物展示服务预约包括寄养、洗护、宠物问诊商品交易就是宠物用品在线购买。一个项目不需要三个方向全覆盖大多数演示级别的系统都会挑其中一个方向做深做强。我在实际项目里最常见的组合是宠物信息展示 领养申请 寄养预约 后台管理。这四个模块能天然覆盖“用户端前台”和“管理端后台”两条线既能看到宠物列表、详情、申请表单这类普通用户的页面又能看到数据管理、审核、订单处理这类后台页面答辩时的素材就非常充足。1.2 为什么是SpringBootVue而不是其他方案这个组合在高校项目和中小型公司内部系统中出现频率极高背后的原因不是跟风而是它确实踩中了这个量级项目的几个关键点。SpringBoot解决的是Java后端“启动成本高、配置繁琐”的痛点。它内嵌了Web容器打出一个jar包就能跑对部署演示非常友好同时它的自动装配机制让数据源、Redis、拦截器这些常见组件的接入成本大幅降低。对于一个需要快速验证业务逻辑的系统SpringBoot几乎是成本最低的起步选择。Vue这边胜在渐进式和组件化。宠物服务平台页面数量不少但结构高度重复——宠物卡片、信息表格、审批表单、弹出对话框本质就是同一套交互逻辑的多次复用。Vue的组件写好后内部只需要传不同的数据源页面就能整体铺开开发效率非常高。还有一个隐藏加分项前后端分离本身就是一个可以聊的技术点。你在答辩时可以说“后端只提供RESTful接口前端通过异步请求消费数据”这句话背后意味着端口分离、跨域处理、接口约定、部署分离等一系列问题每一个都能展开讲比那些套壳的快速开发框架更像一个“能聊技术”的项目。1.3 角色权限与页面清单设计权限模型不需要搞得很重一般两级角色就够普通用户和系统管理员。用户端负责浏览、申请、预约、查看个人记录管理端负责宠物信息维护、申请审核、订单管理、公告发布。关键是“前端控制展示、后端控制数据”的双重校验思路。前端通过路由守卫控制页面能不能看到后端通过拦截器控制接口能不能访问两者缺一不可。否则绕过页面直接调接口就是大漏洞。2. 数据库设计与核心模块先把表设计明白2.1 核心表结构与关系数据库是这类系统最容易做糊的部分。很多源码的表结构改起来很痛苦就是因为一开始没想清楚哪些表是核心、哪些是附属。我在宠物服务系统里通常会建这些表用户表、宠物信息表、领养申请表、寄养订单表、宠物分类表、公告表、留言或评论表。如果涉及商品交易再补商品表、订单表和购物车表。名字直接用user、pet、adopt_application、boarding_order这种看得懂的命名别用一堆缩写后期维护时你会感谢自己。几个容易被忽视的设计点宠物图片不要只存一个URL现实中一只宠物往往有多张照片。用逗号分隔或者JSON字符串存多个URL前端再拆分成数组展示这种方案实现成本低运营维护也方便。申请记录必然要区分状态待审核、已通过、已驳回。这个状态字段在领养申请、寄养订单里都会出现建议用tinyint存状态码Java侧用枚举或者常量类统一定义比散落的字符串更安全。用户和宠物之间是关联查询的高频场景比如“我发布的宠物”“我提交的领养申请”。可以在宠物表直接建user_id字段通过逻辑关联查询不加物理外键。物理外键在数据量上来后会影响写入性能而且删除时容易触发约束演示阶段实在没有必要。2.2 状态机设计为什么状态字段不能乱写领养申请的状态流转看起来简单落到代码里却很容易写出“不管三七二十一直接update status”的粗放逻辑。这么写不是跑不通而是后续每一个查“为什么状态乱了”的夜晚都会让你后悔。状态机这件事一句话说就是把“状态从哪来到哪去”固定下来。比如领养申请的合法路径是待审核 - 已通过/已驳回。寄养订单的合法路径是待支付 - 已确认 - 服务中 - 已完成或者中途取消。在接口层你只需要加一个校验当前状态是否允许变更为目标状态。这个细节在开发阶段看起来多写了几个if但在答辩环节是一个非常好的加分点。老师问“你怎么防止用户把已驳回的申请改成已通过”你能从状态机、枚举定义、校验方法三个层面给出答复这个问题就变成你的展示题了。2.3 索引与查询优化的基本动作演示项目一般数据量不大但代码里养成建索引的习惯面试和答辩时都是加分项。经验之谈所有外键和常用查询条件字段都建普通索引比如user_id、pet_id、status联合查询频率高的场景建复合索引比如根据分类和发布时间筛选宠物列表可以建(category_id, create_time)。分页一定要用limit参数化避免一次性把几千条数据全查出来。模糊搜索尽量避免两条%包住的like查询宠物名称搜索用“前缀%”写法还能勉强走索引双%基本就是全表扫描数据量一大就吃力了。3. 后端工程如何组织从接口拆解到安全控制3.1 分层包结构与职责边界拿到源码第一步先看包结构。规范的宠物服务后端大概会长这样controller放接口入口、service放业务逻辑、mapper负责数据库操作、entity是对应表的实体类、common放公共返回类和常量、config放配置类、security或interceptor放鉴权相关。分层这件事最大的意义不是“看起来规范”而是出问题时能快速定位。我见过不少同学把数据库查询写在Controller里一个接口两百行一旦报错连错误日志都看不懂在哪更别说改了。正确做法是Controller只做三件事接收参数、调用Service、包装返回结果。业务判断、事务控制、数据处理全部下沉到Service层。3.2 JWT鉴权与拦截器的完整流程鉴权是这类系统里最值得讲的亮点功能也是老师最喜欢追问的部分。流程不复杂用户登录成功后端签发一个JWT令牌返回给前端前端把令牌存在本地存储里每次请求在请求头带上Authorization后端写一个拦截器对所有非白名单接口检查令牌合法性合法就放行不合法直接返回401。具体到代码拦截器需要在SpringBoot中注册填一个排除白名单。常见的白名单是登录接口、注册接口、宠物列表和详情一类的公开查询接口。其他接口一律走校验逻辑。这里有一个安全细节密码存库一定不能用明文或MD5要么用Spring Security自带的BCryptPasswordEncoder要么用加盐哈希。这是一个成本极低但专业度极高的点至少能帮你在“密码安全”这个必问题上拿满印象分。3.3 统一响应体与全局异常处理前后端分离项目最难的就是联调阶段“各说各话”。后端接口有的返回JSON对象有的直接返回字符串报错的时候五花八门前端根本没法统一处理。解决思路是定义一个标准响应体所有接口都返回统一结构。我在项目中习惯用Result 包含三个字段code、message、data。成功时code为200业务异常时code为具体错误码数据内容放data里。配合RestControllerAdvice做全局异常捕获业务代码里只要throw new CustomException(xxx)前端就能拿到格式统一的错误响应。前端拦截器也能因此写得非常简练code不是200就弹message是401就跳登录页。整个项目的错误处理逻辑全部收拢到一条线后期加接口根本不用为错误处理额外操心。3.4 核心接口设计与文件上传以“提交领养申请”接口为例这个接口的核心逻辑是校验用户登录、检查宠物是否存在、检查当前用户是否重复申请、创建申请记录并初始化状态为待审核。重复申请的检查很关键不给它加用户连点五次就会产生五条脏数据。文件上传是宠物系统另一个绕不开的地方。宠物信息必须有图片而后端服务处理上传前一定要在配置文件里把大小限制给足。SpringBoot默认上传大小只有1MB宠物照片一张就超了。建议在配置里设成10MB同时在前端做压缩和格式校验两头都要管。4. 前端工程质量路由守卫、请求封装与组件复用4.1 Axios封装与请求拦截器前端工程别一上来就写页面第一个动手的地方应该是网络请求层。宠物服务平台所有页面都要调接口如果不统一封装几十个页面里散落着几百处重复的axios调用改一个公共逻辑就是一场灾难。封装的核心动作是根据环境变量设置baseURL开发环境指向本地后端地址生产环境指向Nginx反代地址请求拦截器里从本地存储取出token放到请求头响应拦截器统一处理返回值code为200才返回数据403或401统一跳转登录页网络错误统一提示。这一步做完业务页面里调接口就变成一句话的事request.get(/pet/list)返回的必然是已经剥好壳的业务数据。前端代码的整洁度直接上一个台阶。4.2 路由守卫与权限控制前端路由通常分两部分用户端页面和管理端页面。用户端页面登录后可访问管理端页面必须验证“当前用户是管理员”才放行。用Vue Router的全局前置守卫来实现每次路由跳转前检查目标路由的meta信息比如requiresAuth和requiresAdmin。没有登录就跳转登录页登录但不是管理员就提示无权限。这里有个容易想当然的地方前端路由守卫只是用户体验层面的拦截真正决定数据安全的是后端接口的鉴权。前端隐藏了按钮和页面后端没有拦截照样能被绕过。所以前端路由守卫和后端拦截器必须配合使用体感上给用户一个流畅无漏洞的界面底线上由后端兜住所有风险。4.3 通用组件拆分与页面复用宠物系统页面重复度高非常适合组件化开发。宠物卡片组件负责展示宠物图片、名称、品种、领养状态再配上详情按钮分页组件统一下方翻页交互图片上传组件统一上传逻辑和回显规则。我把这些通用组件在一次项目中全部抽出来后后续新增管理页面基本只剩“把表格字段列出来把弹窗表单填一下”这种体力活。这一经验也直接反映了一个开发者的工程能力不是“做完功能”而是“做一个可以持续加功能的结构”。4.4 图片上传组件的联调细节前端图片上传通常用现成的UI库组件但联调时有两个坑经常让人抓狂。第一个是上传地址必须和后端接口完全一致尤其是上下文路径。很多同学前端配了/api/pet/upload后端却写在/pet/upload本地代理还能通上线就404排查半天。第二个是上传接口需要带tokenUI库的上传组件默认不会主动帮你加请求头得用beforeUpload钩子或者自定义请求方法把token塞进去。我的经验是直接把上传组件做成项目内的自定义组件所有特殊逻辑收敛到组件内部业务页面只关心上传成功后的URL字符串存到表单哪个字段。这样后面无论怎么重构业务上传这块都不用再动。5. 部署上线的最短路径jar包与dist的配合5.1 部署前的环境准备宠物服务平台的标准部署形态是后端一个SpringBoot应用跑在服务端某个端口前端一堆静态文件交给Nginx托管两者通过反向代理联通。环境准备按清单来JDK版本要匹配SpringBoot版本SpringBoot 2.7.x配JDK 8或11完全足够但如果你用SpringBoot 3.xJDK版本就必须17以上MySQL版本5.7或8都可以但连接驱动和URL参数要注意8.x版本会多几个配置项前端构建环境Node.js版本跟随项目里package.json的要求走。部署目标机器内存至少2G宠物系统虽然轻量但SpringBoot应用启动加Java进程常驻内存太小会莫名其妙卡顿甚至OOM。5.2 后端打包与启动后端打包就一条命令mvn clean package -DskipTests。第一次跑的同学容易在单元测试环节卡半天跳过后一马平川。打包前必须做的一件事是检查生产环境的配置文件。数据库地址、用户名密码、文件上传保存路径、日志级别这些都是生产环境专属别把本地连接串直接带到线上。推荐的做法是建application-prod.yml启动时指定profile。启动用nohup后台运行日志输出到指定文件。启动完成后先看日志里“Started”字样再看端口监听情况确认服务真的起来了再进入下一步。这里最忌讳的就是跑去查前端结果后端压根没起来。5.3 前端构建与Nginx反向代理前端构建也是单一命令npm run build产物在dist目录。构建完成后把dist文件夹里的文件上传到服务器某个静态目录。Nginx配置的核心是两个location块一个匹配前端静态资源让所有页面请求走静态文件另一个匹配API请求把带有/api前缀的请求转发到后端Java服务端口。这样做的好处是浏览器永远只和Nginx打交道不存在额外跨域问题同时静态资源和动态接口彻底分离前端打包更新时后端服务完全不用重启。5.4 项目初始化与图片目录映射数据库初始化通常会用SQL脚本导入别直接在线上库手动敲建表语句一是有语法风险二是不好回溯。把源码里带的SQL脚本按顺序执行再手动插入一条管理员账号做冒烟测试。图片上传路径是部署时频发的坑点。后端配置的保存路径要么写绝对路径要么是相对当前目录的路径Nginx必须新增一个location把图片URL指向同一个目录。不然最常见的现象就是功能全正常唯独图片加载不出来检查后端日志又没有报错最后发现是Nginx不知道去哪里找文件。6. 踩坑实录与答辩前检查清单6.1 部署期最容易出现的五个问题把这几年来遇到最多的问题列成一个速查表每个都能省你好几个小时现象根因快速处理前端页面正常接口全挂Java后端没启动或接口前缀不匹配检查端口、进程、Nginx转发规则图片裂开控制台404Nginx没映射上传目录在Nginx中增加静态资源location指向上传目录时间显示对不上差8小时数据库连接串没配时区JDBC URL加serverTimezoneAsia/Shanghai上传照片总是提示失败SpringBoot默认大小限制或Nginx请求体限制后端加大配置Nginx加client_max_body_size表名或字段名用了关键字报错MySQL关键字冲突要么改名要么SQL里加反引号6.2 源码到手后的排查顺序如果你手里刚拿到一套源码不要急着双击运行。我的建议是按这个顺序来先找SQL脚本把数据库初始化好再打开后端配置文件把数据源改成自己的启动后端确认登录接口能通再启动前端开发服务器把接口地址指到本地最后才谈改功能。这套流程看起来慢其实最快。很多人直接跳到最后一步改页面前端一直请求失败还以为是代码有bug最后发现后端压根没配置数据库。Debug的顺序就是依赖的顺序先让数据层通再让接口层通最后才是UI层。6.3 答辩演示前怎么准备演示系统前先自己想清楚一条完整业务链路从用户注册、登录、浏览宠物、提交申请到管理员登录后台、审核申请、更新状态能一气呵成走完已经不扣分了。再准备一个反向演示用户提交申请后管理员驳回前端正确显示驳回原因。这个流程能证明你对状态流转的理解。答辩追问的高频问题也要提前准备几套答案token过期后前端如何自动退出、多个用户同时申请同一只宠物怎么防止重复、上传图片有没有校验格式、为什么表之间不用外键、订单并发时库存怎么处理。这些问题都不是刁难而是考察你有没有真正想清楚工程细节。最后再分享一个我个人的实操体会源码只是起点而不是终点。你要在源码里做的第一件事不是加功能而是把每个模块的调用链路完整走一遍在关键Service方法上打上断点亲眼看着一条申请记录如何从Controller走到Mapper状态如何从待审核变成已通过。这个过程走完你就真正“拥有”了这个项目剩下的部署、改需求、答辩就都只是时间问题。