企业官网建设流程全解析

毕业设计这个节点上，很多人都绕不开一套“前后端分离”的项目。尤其是宠物服务平台这类选题，业务直观、模块清晰、技术栈也常见，算得上是一套几乎不会出错的模板。但问题也出在这里：源码拿到手，真正能讲清楚、能部署、能改业务的人，十个里面往往不到一半。这篇就想把这些年基于SpringBoot+Vue做这一类系统的经验和踩过的坑一起理一理，从业务边界、工程结构，到部署上线和答辩准备，一次性说透。

1. 这一选题为什么经久不衰：从需求到技术栈的闭环

1.1 宠物服务平台的业务边界

很多同学拿到标题后第一反应是找代码，这其实反了。真正应该先想清楚的是：宠物服务平台到底要解决什么问题。这决定了你后续改代码、加功能、画架构图时心里有没有底。

从业务上看，宠物服务平台通常在三件事上做文章：信息撮合、服务预约、商品交易。信息撮合包括宠物领养、寻宠启事、宠物展示；服务预约包括寄养、洗护、宠物问诊；商品交易就是宠物用品在线购买。一个项目不需要三个方向全覆盖，大多数演示级别的系统都会挑其中一个方向做深做强。

我在实际项目里最常见的组合是：宠物信息展示 + 领养申请 + 寄养预约 + 后台管理。这四个模块能天然覆盖“用户端前台”和“管理端后台”两条线，既能看到宠物列表、详情、申请表单这类普通用户的页面，又能看到数据管理、审核、订单处理这类后台页面，答辩时的素材就非常充足。

1.2 为什么是SpringBoot+Vue，而不是其他方案

这个组合在高校项目和中小型公司内部系统中出现频率极高，背后的原因不是跟风，而是它确实踩中了这个量级项目的几个关键点。

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，排查半天。第二个是上传接口需要带token，UI库的上传组件默认不会主动帮你加请求头，得用beforeUpload钩子或者自定义请求方法把token塞进去。

我的经验是：直接把上传组件做成项目内的自定义组件，所有特殊逻辑收敛到组件内部，业务页面只关心上传成功后的URL字符串存到表单哪个字段。这样后面无论怎么重构业务，上传这块都不用再动。

5. 部署上线的最短路径：jar包与dist的配合

5.1 部署前的环境准备

宠物服务平台的标准部署形态是：后端一个SpringBoot应用跑在服务端某个端口，前端一堆静态文件交给Nginx托管，两者通过反向代理联通。

环境准备按清单来：JDK版本要匹配SpringBoot版本，SpringBoot 2.7.x配JDK 8或11完全足够，但如果你用SpringBoot 3.x，JDK版本就必须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 部署期最容易出现的五个问题

把这几年来遇到最多的问题列成一个速查表，每个都能省你好几个小时：

6.2 源码到手后的排查顺序

如果你手里刚拿到一套源码，不要急着双击运行。我的建议是按这个顺序来：先找SQL脚本，把数据库初始化好；再打开后端配置文件，把数据源改成自己的；启动后端，确认登录接口能通；再启动前端开发服务器，把接口地址指到本地；最后才谈改功能。

这套流程看起来慢，其实最快。很多人直接跳到最后一步改页面，前端一直请求失败，还以为是代码有bug，最后发现后端压根没配置数据库。Debug的顺序就是依赖的顺序，先让数据层通，再让接口层通，最后才是UI层。

6.3 答辩演示前怎么准备

演示系统前，先自己想清楚一条完整业务链路，从用户注册、登录、浏览宠物、提交申请，到管理员登录后台、审核申请、更新状态，能一气呵成走完，已经不扣分了。再准备一个反向演示：用户提交申请后，管理员驳回，前端正确显示驳回原因。这个流程能证明你对状态流转的理解。

答辩追问的高频问题也要提前准备几套答案：token过期后前端如何自动退出、多个用户同时申请同一只宠物怎么防止重复、上传图片有没有校验格式、为什么表之间不用外键、订单并发时库存怎么处理。这些问题都不是刁难，而是考察你有没有真正想清楚工程细节。

最后再分享一个我个人的实操体会：源码只是起点，而不是终点。你要在源码里做的第一件事不是加功能，而是把每个模块的调用链路完整走一遍，在关键Service方法上打上断点，亲眼看着一条申请记录如何从Controller走到Mapper，状态如何从待审核变成已通过。这个过程走完，你就真正“拥有”了这个项目，剩下的部署、改需求、答辩，就都只是时间问题。