Alabaaaa项目标题里的信息量其实不小：一个完整的“宠物健康咨询系统”，技术栈是 SpringBoot + Vue + MyBatis + MySQL，架构是 B/S。我最初看到这个标题，第一反应是又一个典型的Java全栈课设/毕设项目。但真正动手拉开需求后才发现，宠物健康咨询不是“论坛+留言板”那么简单，它牵扯到宠物档案、用户权限、咨询流转、医生回复、后台管理好几条业务线。这篇就把我当时从零搭这个系统的完整思路、表结构设计、后端接口实现、前端联调，还有踩过的一堆坑都梳理出来，希望能给正在做类似的Java全栈项目、或者准备拿这种题目做毕设的朋友一点实际参考。
为什么要强调B/S架构？说白了就是用户不用装任何客户端，浏览器打开就能用。SpringBoot负责后端接口，Vue负责前端页面，两者通过JSON交互，前后端彻底分离。这种模式的好处是后端只专心处理数据和业务逻辑，前端只专注交互和页面渲染，天然适合多端复用——以后想加个小程序端，直接复用同一套接口就行，不用重写后端。下面我按实际开发顺序，把整个系统的设计过程一步步拆给大家看。
1. 项目整体定位与设计思路拆解
1.1 核心需求解析：宠物健康咨询系统到底要管什么
很多人一听“宠物健康咨询”，第一反应是做个简单的问答社区。真把需求落地时，会发现这里面至少有三类角色、四块核心业务。
三类角色分别是游客、普通用户（养宠人）、管理员（可以兼任宠物医生）。游客只能浏览基础页面；普通用户注册登录后，可以创建和维护自己的宠物档案，发起健康咨询，查看医生回复；管理员负责审核用户、管理宠物分类、维护健康知识库、回复用户的咨询问题。四块核心业务就是用户管理、宠物档案管理、咨询问答管理、健康知识管理。这四条线贯穿了整个系统的数据库设计和接口设计。
我在正式写代码之前，习惯先用三句话给系统画边界：用户能做什么、管理员能做什么、系统要提供什么基础能力。这三句话敲定后，再逐层细化成功能清单和数据表。比如用户侧的“宠物档案管理”细化出来就是添加档案、编辑档案、上传宠物照片、查看档案列表；管理员侧的“咨询管理”细化出来就是查看待回复咨询、输入回复内容、关闭已解决咨询。功能清单明确后，后端要写哪些接口、前端要建哪些页面就一目了然了。
1.2 B/S架构选型的幕后逻辑
B/S架构，Browser/Server，浏览器/服务器架构。在这个项目里，我的选择理由很直接：第一，系统不需要分发客户端。宠物主人随时可能在手机或电脑上打开浏览器问诊，如果做成C/S架构的桌面程序，不仅用户要下载安装，后期每次升级都得重新发版，用户体验非常差。第二，系统的并发读写压力并不高，B/S架构配合后端连接池完全撑得住。第三，前后端分离的B/S模式正好契合SpringBoot+Vue的主流光组合，后端接口对前端完全透明，前端怎么展示、用什么框架都可以自由替换。
当然B/S架构也有它的短板，比如浏览器环境差异导致样式兼容问题、弱网情况下交互体验不如原生客户端流畅。但这些在管理类业务系统里都属于可接受范围。更关键的是，B/S架构天然利于集中部署和权限管控。系统只需要部署在一台服务器上，数据库、文件资源、后端服务统一管理，安全性比数据散落在各客户端的C/S模式好控制得多。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 技术栈选型解析：SpringBoot、MyBatis、Vue三者的分工
2.1 SpringBoot版本选择：不是越新越好
版本选择是很多新手第一个翻车点。热词里那句“springboot版本太高”我太有体会了。SpringBoot 3.x把javax命名空间整体换成了jakarta，很多老教程里的代码直接报ClassNotFoundException；如果项目里引用的第三方库还没适配新规范，光是解决依赖冲突就能耗掉大半天。我的建议是，做这类管理类系统，SpringBoot 2.7.x + JDK 8是最安逸的组合。这个版本经过大量生产环境验证，资料多、排错容易、兼容性强。
SpringBoot的核心价值是自动配置和“约定优于配置”。开发时我基本不用写XML配置文件，一个application.yml搞定数据源、端口、MyBatis映射路径等核心配置。再配合起步依赖spring-boot-starter-web、spring-boot-starter-jdbc，依赖版本都由SpringBoot统一管理，不需要自己操心版本冲突。如果项目想自定义Banner，直接用网上在线的SpringBoot Banner生成器生成一段ASCII字符画，复制进banner.txt，启动时控制台就会显示，纯属提升开发心情的小操作。
2.2 MyBatis相比JPA的优势：SQL可控性带来的安全感
宠物健康咨询系统里有不少多表联查场景，比如查询某只宠物近期的咨询记录，需要关联宠物表、咨询表、回复表。MyBatis最吸引我的地方就是SQL完全由自己掌控，复杂查询想怎么写就怎么写，SQL优化空间也大。JPA虽然写CRUD很快，但遇到稍复杂的动态查询时，要么拼接JPQL，要么写Specification，总感觉隔了一层纱。
MyBatis的<if>动态SQL能力在咨询筛选场景里特别实用。比如实现“按宠物类型+咨询状态+时间范围”组合筛选时，用<where>和<if>组合，有值才拼条件，代码干净且安全。当时我还遇到过一个需求：状态字段存的是用逗号分隔的多个值，需要在<if test="xxx.indexOf('已回复') != -1">，这种写法可以直接在OGNL表达式里判断字符串包含关系，比在Java层先算好布尔值再传入更直接。
2.3 Vue前端框架：渐进式开发带来的效率提升
前端选用Vue，核心考虑是组件化开发和双向数据绑定。组件化让页面代码可以按功能拆分，比如宠物档案卡片、咨询列表项、回复输入框都各自是独立组件，不仅复用方便，维护时也只需改一处。双向数据绑定则大幅简化了表单类页面的开发，不需要像传统jQuery那样反复操作DOM，数据模型变了页面自动更新。
Vue 2和Vue 3之间我选了Vue 2。原因很实在：项目里的UI组件库和现有教程生态更成熟，Vue 3的Composition API固然更好，但团队学习成本摆在那里。如果你是从零开始学，我建议直接上Vue 3 + Vite + Element Plus，这套组合更现代；但如果只是想快速完成一个课设项目、网上的现成模板又大多基于Vue 2，那用Vue 2也未尝不可，关键是别在项目中途频繁切换版本。
3. 数据库设计：一张表一张表细说
3.1 用户表设计：账号、角色和基础信息
用户表是整个系统的地基，字段设计直接决定后续权限模块的复杂度。我当时设计的user表包含：id主键、username用户名、password密码（BCrypt加密后存储）、nickname昵称、phone手机号、avatar头像URL、role角色（0表示普通用户，1表示管理员）、create_time创建时间、status账号状态（0正常，1禁用）。
这里要聊一个很多新手容易忽略的点：密码绝不能明文存储。用Spring Security的BCryptPasswordEncoder或者Spring Security Crypto里的工具类做加密，即使数据库泄露，攻击者也拿不到明文密码。用户登录时用matches()方法比对明文和密文即可。另一件需要注意的事是role字段不要用字符串直接写“admin”或“user”，用数字枚举值存储，查询效率高，也不容易拼写错误。
3.2 宠物档案表设计：把宠物当成“用户的核心资产”
宠物档案是咨询功能的前置条件。系统需要记录每只宠物的基本信息，字段包括：id、user_id所属用户、pet_name宠物名、pet_type宠物种类（猫/狗/其他）、pet_breed品种、pet_birthday出生日期、pet_gender性别、pet_weight体重、pet_avatar宠物照片、pet_note备注信息、create_time创建时间。
这里会有个数据库字段类型的小决策：pet_birthday我用的是date类型，计算年龄时在Java里用LocalDate处理会非常灵活。前端展示时，利用Vue的computed特性根据出生日期动态计算“X个月/Y岁”，这个逻辑放前端做的好处是不用每次改宠物年龄都请求后端。另外，pet_type和pet_breed我建议单独建字典表维护，一是避免用户随意填导致数据杂乱，二是后续好做分类统计。宠物品种的选项在系统管理端配置，用户下拉选择即可。
3.3 咨询表与回复表：核心业务的数据流转
咨询模块我拆成了两张表：consultation咨询主表和reply回复表。
consultation表字段有：id、user_id提问用户、pet_id关联宠物、title咨询标题、content咨询详细描述、status处理状态（0待回复，1已回复，2已关闭）、create_time发起时间、handle_time处理时间。reply表字段有：id、consultation_id关联咨询、admin_id回复管理员、content回复内容、create_time回复时间。
这样设计的好处是：一个咨询可以有多次回复，形成一对多的关系。有些系统为了省事，把回复内容直接塞在咨询表里，一旦用户追着追问，就不得不再建一条新咨询，业务上其实很别扭。我经历过这个坑，所以在设计时果断选择拆分表，回复记录保留完整的沟通轨迹，管理员后台也能看到每次处理的详细日志。查询咨询列表时，使用LEFT JOIN把宠物名和用户名拼上，前端展示一个列表页搞定，不需要反复请求详情接口。
4. 后端核心模块实现：从登录认证到咨询全链路
4.1 JWT登录认证与拦截器配置
登录认证我选的是JWT（JSON Web Token）。流程是：用户提交账号密码，后端校验通过后生成一个带有用户ID和角色的token返回给前端。前端把token存在localStorage里，每次请求在拦截器中带上Authorization请求头。后端写一个拦截器，对所有非登录接口做token解析，解析失败直接返回401。
JWT的好处是服务端无状态，不需要像Session那样在服务端保存会话信息。但要注意token过期时间设置，我设的是24小时。管理端接口的安全性要求更高，拦截器里还要额外校验role == 1，防止普通用户通过猜测接口路径访问管理功能。这类接口级权限控制一定要做，不能只依赖前端隐藏按钮。
实际开发中，拦截器注册是个容易踩坑的地方。在SpringBoot里要继承WebMvcConfigurer重写addInterceptors方法，并且excludePathPatterns里要放行登录接口、注册接口、静态资源路径。如果配置不当，最常见的现象是跨域请求被拦截，或者静态页面无法访问。
4.2 宠物档案管理与图片上传
宠物档案的CRUD没有太大难度，真正会绊倒人的是图片上传。我当时的做法是：前端把图片文件通过multipart/form-data方式POST到后端的/upload接口，后端用MultipartFile接收，将文件保存到服务器本地指定目录（比如/usr/local/upload/pet/），文件名用UUID重新生成，避免文件名冲突。保存完成后把访问URL返回给前端，数据库只存这个URL字符串，文件本身不在数据库里。
这里有一个关键的配置：需要给静态资源目录做映射，把/upload/**路径映射到本地磁盘目录。SpringBoot里用addResourceHandlers方法，比如registry.addResourceHandler("/upload/**").addResourceHandler("file:/usr/local/upload/")。如果不做这一步，前端拿到URL无法访问图片，会一直404。另一个要注意的点是文件大小限制，SpringBoot默认单文件最大1MB，如果宠物照片稍微大点就报错，需要在application.yml里设置spring.servlet.multipart.max-file-size: 10MB和max-request-size: 10MB。
4.3 咨询模块的事务控制与状态流转
用户发起咨询时，后端核心逻辑是生成一条consultation记录，状态置为“待回复”。管理员回复时，后端同时做两件事：写入一条reply记录，并且把consultation的status改成“已回复”。这两步操作必须放在同一个事务里，否则可能出现“回复内容写了但状态没更新”的脏数据。
在SpringBoot中实现事务很简单，Service方法上加@Transactional注解即可。但要注意：事务默认只在RuntimeException时回滚。如果你在代码里手动catch了异常却忘了抛出，事务不会生效，数据就会错乱。我自己的习惯是Service层不轻易吞异常，捕获后要么抛出运行时异常，要么用TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()强制回滚。
咨询列表的数据分页我用的是MyBatis的分页插件PageHelper。使用上非常方便，PageHelper.startPage(pageNum, pageSize);后面紧跟着的查询SQL就会自动分页，返回的PageInfo对象里直接带total总数、list列表等字段，前端分页组件直接对接。还有一个细节：startPage之后必须紧跟一句查询，中间不能插入其他数据库操作，否则分页会失效。
5. 前端Vue页面搭建与接口联调实录
5.1 路由设计：前后端页面如何组织
前端页面我分了这几块：首页（宠物健康知识展示）、用户登录/注册页、用户个人中心（包含宠物档案管理、我的咨询）、管理后台（用户管理、宠物管理、咨询管理、健康知识管理）。路由用Vue Router配置，在router/index.js里定义路径和组件映射。
权限控制方面，我在前端路由的meta字段里加了requiresAuth和adminOnly标记。全局前置守卫router.beforeEach里做统一判断：未登录且需要登录态的页面，直接重定向到登录页；非管理员访问管理后台，提示无权限。这种做法虽然前端无法做到绝对安全（真正安全要靠后端接口校验），但能显著改善用户体验，避免用户看到一堆空白页面或者红屏报错。
5.2 Axios封装：让接口调用变得清爽
项目中的前端请求我统一用Axios，并且封装了一个request.js模块，做三件基础事：统一设置baseURL、请求拦截器自动携带token、响应拦截器统一处理错误码。
响应拦截器是最容易出效果的部分。后端接口我约定统一返回格式{code: 200, message: "success", data: {...}}。拦截器里判断code，等于200就直接返回data；不等于200就弹出错误提示；遇到401时自动清理本地登录信息并跳转登录页。这样一来，页面里写业务代码时就不需要写大量的错误分支，请求调用处只关心成功后的数据逻辑。个人中心里宠物列表、咨询列表、健康知识列表都共用同一套封装，代码量大幅减少。
5.3 宠物年龄计算：Computed的典型场景
宠物档案卡片上有个月龄展示，根据宠物出生日期动态算出几个月大。这个逻辑非常适合用Vue的computed实现。在组件里定义ageText计算属性，内部获取pet.birthday，用dayjs或原生Date做差值计算，返回“3个月”或“2岁5个月”这样的文本。宠物信息更新后，计算属性自动重新计算，不需要手工触发更新。
这里还要提一个联调中的常见问题：后端接口返回的时间格式。SpringBoot调用Jackson序列化LocalDateTime时，默认输出类似"2024-01-15T10:30:00"。前端直接显示没问题，但如果是“发帖时间”这种展示需求，最好后端配置统一的Jackson日期格式yyyy-MM-dd HH:mm:ss，前端少做一层转换。我当时的做法是spring.jackson.date-format加上time-zone: GMT+8，不然月份日期会少8小时，非常迷惑。
6. 高频报错排查与避坑实录
6.1 SpringBoot集成MyBatis一直报错的典型场景
热词里有一句“eclipse里springboot集成mybatis一直报错。downloading…”，这个我太有共鸣了。大部分人遇到的问题是MyBatis的mapper-locations没有配置对。XML文件放在resources/mapper目录下，但application.yml里没有写mybatis.mapper-locations: classpath:mapper/*.xml，导致Spring启动时找不到Statement，运行时报Invalid bound statement (not found)。
另一个很容易忽略的点是@MapperScan注解。如果启动类上没有指定@MapperScan("com.xxx.mapper")，或者单个Mapper接口上没加@Mapper注解，Spring容器就不会把Mapper接口注入进来，启动时疯狂报No qualifying bean of type。这个错误信息看着吓人，排查起来其实一分钟就能定位。我的建议是启动类直接用@MapperScan扫包，接口上就不用每个都写@Mapper了，清爽很多。
6.2 MySQL连接和更新操作常见问题
MySQL 8.x和5.x在连接上有个大区别：驱动类从com.mysql.jdbc.Driver改成了com.mysql.cj.jdbc.Driver，URL还要加上serverTimezone=Asia/Shanghai和useSSL=false，否则会报时区错误或者SSL握手失败。依赖坐标也有变化，MySQL 8对应的是com.mysql:mysql-connector-j，不是老版的mysql:mysql-connector-java。我用MySQL 8.0.33时踩过这个坑，pom里引错坐标直接编译报错。
还有一个数据库操作细节，关于热词里提到的“mysql中int+5”。如果你写UPDATE pet SET age = age + 5 WHERE id = 1，在MySQL里没问题，但要注意age如果是TINYINT（范围-128~127），加几次就可能溢出。我当时设计宠物年龄时就没直接用年龄字段，而是存储生日，涉及年龄计算都通过程序实时算。这种设计的好处是数据只有生日一个真实来源，不会出现“年龄字段和生日对不上”的尴尬情况。如果项目里确实要用数值字段做加减，一定要评估字段类型范围，int类型最大21亿，一般业务够用，但别在小字段上省空间。
6.3 前端常见报错：跨域、白屏和404
前后端分离开发时，最大的拦路虎是跨域。前端地址是localhost:8080，后端是localhost:8081，浏览器出于同源策略会拦截请求。解决方法有两种：后端在WebMvcConfigurer里配置CORS映射，或者前端通过Vite开发服务器配置proxy代理。我建议两种都懂：本地开发用代理，部署到服务器后用Nginx反向代理同一端口，就不存在跨域问题。
前端白屏的排查思路也很固定：如果首页白屏但没报错，优先看控制台的JS报错信息；如果只是某个路由白屏，检查路由配置里组件的路径是否正确，特别是大小写。之前有一次我把组件放在views/consult/目录，路由里写成了views/Consult/，Windows本地开发没事，但Linux服务器上JAR包部署后访问直接404，因为Linux文件系统是大小写敏感的。
6.4 Java内存溢出：OutOfMemoryError的常见修复路径
项目里如果图片上传多了，或者前端频繁刷新大数据列表，后端偶尔会报java.lang.OutOfMemoryError: Insufficient memory。这个报错本质上是JVM堆内存不足。我的排查思路是：先看是堆内存不够还是元空间不够；堆不够就调大-Xmx，元空间不够就调大-XX:MaxMetaspaceSize。本地IDE里直接在VM options配，服务器上在启动命令里加参数，比如java -Xms256m -Xmx1024m -jar app.jar。
但调大内存不是根本解决办法。如果列表接口每次查全表返回几千条数据，内存当然扛不住。要配合分页查询、后端字段裁剪等方案一起用。我在咨询列表里用PageHelper分页后，内存占用直接降了一个数量级。这种“先压缩数据量，再调大内存”的思路，才是治标又治本的方式。
7. 打包部署与上线配置要点
7.1 后端打包：SpringBoot的Jar部署
后端打包非常简单，配好Maven后执行mvn clean package，生成可执行的JAR包。但要注意几个配置，不然部署后各种小毛病。
application.yml里数据源配置不要写死成本地的localhost和测试账号，部署时通过外部配置覆盖，比如java -jar pet-system.jar --spring.config.location=/usr/local/pet/application-prod.yml。这样代码仓库里不泄露数据库密码，部署环境也灵活。如果用的是MySQL 8，记得在服务器上确认版本一致，避免本地连接正常、线上驱动不兼容。
7.2 前端打包：从Vue到静态文件
前端执行npm run build，生成dist目录，里面是纯静态文件。部署方式一般是：把dist里的文件复制到Nginx的html目录，配置Nginx把/api开头的请求反向代理到后端端口。这里有个关键配置：因为前端路由用了history模式，Nginx还需要配置一个try_files规则，把前端路由的URL都指回index.html，否则刷新页面会404，比如用户访问/consult/12，刷新直接白屏。
我实际用的Nginx关键配置大概是这样的（不需要完整生产配置，核心逻辑就是前端路由回退和反向代理）：静态文件指向dist目录，location /走try_files $uri $uri/ /index.html，location /api反代到http://127.0.0.1:8081。如果MySQL和后端都在同一台服务器，记得在安全组里放行对应端口，不然外部访问不通。
7.3 服务器环境检查清单
部署前我建议列个清单逐项确认：1）JDK版本是否和后端一致（JDK 8对应JDK 8，别装个JDK 17就跑8编译的包）；2）MySQL编码是否utf8mb4，不然中文存储有乱码风险；3）服务器时间是否正确，时区不对会导致JWT过期时间判断出问题；4）上传目录有没有创建、是否有读写权限。这些看起来琐碎，但每一项都可能导致线上运行事故，提前排查能省去事后救火的时间。
8. 写在最后：从项目角度聊聊我的体会
这套系统从头到尾做下来，我最深的感受是：项目难点从来不在某个单一技术点，而在于把散落的需求用合理的结构串起来。 宠物健康咨询系统表面上是CRUD，但真正做完后，你会知道JWT怎么跟拦截器配合、事务注解为什么不能吞异常、Nginx前端路由为什么需要try_files、数据库表为什么需要拆成主表和明细表。这些是背面试题背不出来的，只有亲手做完一个全栈项目，踩过那些坑，才能在下次遇到类似需求时迅速给出合理的方案。
最后再分享一个小技巧：做这种全栈项目时，先把前端的api目录和所有的请求函数定义好，字段名跟后端VO的字段名对齐，两边并行开发时根本不需要频繁联调。比如我的宠物档案接口返回字段是petName，前端请求函数里就直接写petName，不要在中间再做一层转换，字段口径统一，能省掉大量沟通成本。
如果你正在做类似的Java全栈系统，我的建议是不要一上来就写代码，先画好表结构、列好后端接口清单、定好前端路由和核心组件，这三样东西就相当于施工图纸。图纸清楚了，后面每一步都有章可循。照着这个流程来，宠物健康咨询系统也好，其他什么管理系统也好，做出来的东西都不会差到哪去。