SpringBoot+Vue前后端分离：宠物服务平台开发实战与踩坑总结

1. 这个宠物服务平台到底解决了什么问题技术栈又是怎么权衡出来的先说我自己的背景。断断续续接了不少类似“XX管理系统”“XX服务平台”的外包和毕设辅导这类项目最大的特点是业务不复杂但功能面非常杂。宠物服务平台尤其典型它不像电商系统那样围绕“商品—订单—支付”一条主线就能扯清楚它涉及用户注册登录、宠物档案维护、服务预约、订单状态流转、资讯/社区内容展示、后台管理等多个互相独立的业务域。如果一开始没有把技术架构理清楚做到一半必然这改一下那改一下最后项目代码变成一团乱麻。这个项目核心面向两类使用者C端用户养宠人和B端管理者平台运营或门店店员。C端能逛宠物知识文章、给自家宠物建档案、下单预约洗澡美容寄养等服务B端管理后台则维护服务项目、排班、处理订单状态。整个系统的目标用一句话概括让“养宠人找服务”和“门店管订单”两条业务流程在一个系统里闭环跑通。技术选型上我最终定了SpringBoot Vue前后端分离的方案这也是当前Java技术栈里最主流、资料最多、踩坑成本最低的组合。为什么不用传统的Thymeleaf服务端渲染原因很现实这个项目的前端交互密度不低用户端有预约时间选择、宠物档案卡片、订单进度时间轴管理端有数据表格、弹窗表单、状态标签这些都是典型的前后端交互场景。用服务端模板做前端逻辑和后端模板混在一起后期每改一个交互都要动Controller和HTML维护成本太高。而前后端分离之后后端只需要把接口定义清楚前端专注交互两个人可以并行开发一个人做的话逻辑边界也会更清晰。还有一点必须提的是SpringBoot版本的选择。现在很多人一上手就选最新版SpringBoot 3.x但我做这个项目用的是SpringBoot 2.7.18。原因有两个一是很多教学资源、插件、第三方starter对2.x的兼容性验证最充分出了问题搜解决方案效率高二是2.7.x是2.x系列最后一个稳定维护版本安全性没有问题而且对JDK8的兼容非常友好。如果自学或做毕设没必要为了“新”去折腾兼容性问题。提示如果你选定SpringBoot 2.7.xJDK保持1.8即可如果非要用SpringBoot 3.x那JDK至少17起步MyBatisPlus、Druid等组件的依赖版本也要配套升级这是个连环过程。2. 数据库表设计从宠物档案到服务订单这几张表把业务撑起来了很多做这类项目的人会犯一个通病拿到需求直接开建表边写代码边加字段。我一开始也这样结果就是订单表里冒出一个pet_notes宠物备注字段排在order_status后面看代码的人一脸懵连我自己过两周再看都想不起来当初为什么加它。所以这次我老老实实从“业务对象—关系—状态”三个维度先做了表结构梳理后面写代码的速度反而快了很多。2.1 用户体系与宠物档案为什么一定要拆成两张表用户表user是最基础的一张表字段包括id、username、passwordBCrypt加密后的密文、nickname、avatar、phone、role用来区分C端用户和管理员、status、create_time。关键点在宠物档案表pet的设计上。一张宠物档案应该归属于某个用户所以设计为owner_id外键关联user.id。宠物本身的属性包括pet_name、pet_type猫/狗/其他用数字字典或字符串枚举都行、breed品种、birthday、gender、weight、avatar、is_neutered是否绝育、vaccine_status疫苗接种情况。为什么用户和宠物必须拆开而不是在用户表里存一个“宠物名”的字段我见过有同学图省事这么干后续做功能时立刻翻车预约服务时需要显示宠物列表让用户选如果宠物信息存在用户表要么一个用户只能养一只宠物要么就得搞出pet_name1、pet_name2这种反人类设计。拆成两张表后用户和宠物是一对多关系天然支持多宠物扩个宠物数量上限也就是加个字段的事。2.2 服务项目、预约单、订单三张核心表的状态流转设计服务项目表service_item相对简单id、service_name如“猫咪洗澡SPA”、service_type洗澡/美容/寄养/医疗、price用decimal(10,2)、duration服务时长分钟为单位、cover_image、description、status上下架状态。真正的核心是预约单表appointment。它承担了用户与门店之间的“预订”动作关键字段包括iduser_id预约人pet_id哪只宠物service_id预约的服务appointment_date预约日期appointment_time_slot时间段如“09:00-10:00”status0待确认1已确认2已完成3已取消remark备注create_time这里我需要重点解释一下time_slot字段的设计。预约功能天然有时间冲突校验的需求同一个时间段不能同时被两个用户约走。存一个字符串类型的time_slot业务校验时直接比对“同一天 同一个时间段 状态为待确认/已确认”是否存在记录简单高效。如果你要做更精细的时段并发控制可以额外建一张service_schedule表来维护每个服务项目的可约时段和剩余名额但毕设和一般实战项目用appointment表自带日期时段字段的方式足够。订单表order是预约确认后生成的支付单据字段id、order_no唯一订单号用时间戳加随机数生成、appointment_id关联预约单、user_id、total_amount、pay_status0未支付1已支付、pay_time、create_time。预约和订单分开的好处是用户可以“预约后到店再付款”而不是线上支付流程强绑定预约流程。如果一开始就把支付硬塞进预约流程支付环节出现异常会导致预约状态不可控实际做项目时这是最常见的状态混乱来源。2.3 社区资讯与留言评论的表设计内容分享模块资讯文章、养宠心得是大多数宠物平台的标配。文章表article字段id、title、cover_image、content比如用长文本类型存富文本HTML、author_id、view_count、create_time。评论表commentid、article_id、user_id、content、create_time。这两张表要关联查询写文章详情接口时连表查出作者昵称和评论列表即可。一个我踩过的坑富文本内容直接存HTML时如果你用MyBatis-Plus的自动填充功能create_time字段可能因为格式化问题在插入报错。建议实体上用LocalDateTime数据库字段用datetimeMyBatis配置里加一个全局的jdbcTypeForNullNULL避免空值插入时驱动报错。3. 后端接口落地的几个关键实现认证、校验、状态机一个都不能少后端技术栈我选了SpringBoot 2.7.18 MyBatis-Plus MySQL 8.0 Redis。MyBatis-Plus帮我把单表CRUD的样板代码压缩到了最低复杂查询用它的LambdaQueryWrapper也能写出比较清晰的API。Redis在这个项目里主要用来存验证码和做接口缓存JWT也用它做黑名单控制注销登录时让token失效。3.1 JWT登录认证的完整链路拦截器到底该怎么设计登录流程很多人已经写过无数遍了用户传用户名密码后端校验通过后用JWT生成token返回给前端前端把token存localStorage之后每次请求在请求头加Authorization: Bearer token后端拦截器统一解析。这个流程本身没毛病但实际落地时有几个细节很容易翻车。先说拦截器的设计。我新建了一个JwtInterceptor实现HandlerInterceptor接口在preHandle方法里做三件事取请求头token、解析token、把用户信息塞进ThreadLocal。需要注意拦截器要排除登录注册接口、首页轮播图、文章列表这些无需登录的公开接口否则用户还没登录就调不通基础页面。排除名单我维护在WebMvcConfig里用一个字符串数组统一配置registry.addInterceptor(jwtInterceptor()) .addPathPatterns(/**) .excludePathPatterns( /api/user/login, /api/user/register, /api/article/list, /api/article/detail/**, /api/home/banner, /error );然后是ThreadLocal的使用。一个请求从进入拦截器到Controller再到Service如果在每个方法里都手动传一遍当前登录用户的id代码里全是这种参数非常丑。我用了一个UserContext工具类内部放ThreadLocal存储LoginUser对象包含用户id、用户名、角色在拦截器解析token后写入请求结束时在afterCompletion里remove掉。这样Controller直接UserContext.getUserId()就能拿到当前用户。注意ThreadLocal用完必须remove尤其是在线程池场景下否则线程复用会导致用户数据串号。这个问题线上出过事故排查了一下午才发现是漏了remove操作。JWT在SpringBoot里主流方案是io.jsonwebtoken:jjwt0.9.1版本对应JDK8如果你在JDK8环境引了0.12.x启动时大概率会遇到NoClassDefFoundError就是因为jjwt新版本把依赖拆分了需要额外引入jjwt-api、jjwt-impl、jjwt-jackson三个模块。这是很典型的SpringBoot新手踩坑点。3.2 预约服务的时间冲突校验并发场景下的一个隐形Bug预约功能的核心接口是“提交预约”前端传petId、serviceId、appointmentDate、timeSlot、remark。后端要做三层校验用户是否登录、宠物是否属于当前用户防止提交别人的宠物id服务项目是否处于上架状态该日期时间段是否已被预约占用第三层的冲突校验是误伤最多的地方。如果只是简单地SELECT * FROM appointment WHERE date ? AND time_slot ? AND status IN (0,1)查出来发现没记录就允许插入这在并发情况下两个用户同时抢最后一个时段会同一时段同时插入两条。要根治的话先给appointment表加一个唯一索引索引字段是appointment_datetime_slotservice_id数据库层面兜底。然后再做业务判断先查再插如果插入时捕获到DuplicateKeyException就说明被并发抢占了直接提示“该时段已被预约”。这套方案在单机部署的毕设和小型项目里够用了。3.3 订单状态机别用一堆if-else硬撑订单状态我定了一个简单状态机0待支付预约确认后创建1已支付用户点击支付后更新2已完成门店确认服务完成后更新3已取消用户取消或超时未支付由后端定时任务更新这个状态机虽然简单但必须规定好“谁可以变更到哪个状态”。我写了一个OrderStatusService里面只有一个transition方法传入当前状态、目标状态、操作类型用switch判断合法流转路径非法流转直接抛业务异常。这样订单状态相关代码集中在一处前端在订单列表显示状态流转按钮时也可以根据当前状态动态决定显示哪些操作按钮前后端的状态逻辑完全对齐。有个细节用户取消订单的操作要区分“未支付”和“已支付”两种情况。未支付直接取消即可已支付的订单取消后要触发退款这里一般对接微信/支付宝退款接口毕设阶段可以只做状态流转并注释说明退款对接点。我把这个逻辑放在Service层而不是在Controller里写if判断目的是让状态变更逻辑不分散、可复用、可测试。3.4 MyBatis-Plus分页查询与条件构造器使用心得分页是管理端List页面的刚需。MyBatis-Plus内置了分页插件但很多人引入后不生效原因是在配置类中没有把PaginationInnerInterceptor加入MyBatis-Plus拦截器链。正确的配置Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; }配置完成后Service里直接page(new Page(current, size), queryWrapper)就能拿到分页数据。返回给前端时我一般包装一个统一响应体RT里面包含code、msg、data三个字段分页时data是PageResult对象里面放records列表数据、total总条数、current当前页、size每页数量。前端拿total渲染分页组件的总页数拿records渲染表格。条件构造器建议用Lambda版本也就是LambdaQueryWrapperT好处是字段名用方法引用User::getUsername而不是字符串username。这样即使将来字段重命名编译器能帮你检查出来不至于运行时报SQL错误。4. 前后端联调中的真实痛点跨域、日期格式、图片上传路径前后端分离的第一步是把前端Vue开发服务器默认8080端口和后端SpringBoot接口服务默认8081端口联起来。这个环节是大多数项目卡壳的第一个点翻来覆去就那几个问题。4.1 跨域问题别只靠注解还要理解它为什么发生后端接口返回正常前端浏览器控制台报Access-Control-Allow-Origin错误这是跨域。前后端分离最大的坑就在这——浏览器同源策略限制了Script发起的跨域请求而Vue的devServerlocalhost:8080和SpringBoot接口localhost:8081端口不同属于不同源。解决方式也有几种最简单粗暴的是在Controller上加CrossOrigin但这样每个接口都要加或者类上加了但全局配置没跟上容易漏。我更推荐在SpringBoot全局配置类里统一允许跨域Configuration public class CorsConfig { Bean public CorsFilter corsFilter() { UrlBasedCorsConfigurationSource source new UrlBasedCorsConfigurationSource(); CorsConfiguration config new CorsConfiguration(); config.addAllowedOriginPattern(*); config.addAllowedHeader(*); config.addAllowedMethod(*); config.setAllowCredentials(true); source.registerCorsConfiguration(/**, config); return new CorsFilter(source); } }注意如果你同时用了Spring Security跨域配置一定要放在Security的授权链之前否则Security的过滤器先拦截CORS跨域配置根本进不来报错依然是跨域。这个坑我在一个项目里踩了整整半天。更让人崩溃的是本地联调好了部署到服务器后跨域又出现了。因为Vue打包后的静态文件放在Nginx里和SpringBoot接口不在同一个域。我最后采用的方案是不在后端做跨域放开而是通过Nginx反向代理把/api/路径的请求转发到后端的localhost:8081这样前端所有请求都是同源的从根本上规避了跨域。4.2 日期时间格式问题前端显示Invalid Date的排查经历列表接口返回订单数据后前端表格里时间那一列显示Invalid Date。一开始怀疑是前端组件问题查了半天发现是后端返回的时间格式不是前端能直接处理的格式。后端实体类如果用LocalDateTime默认序列化出来是2025-06-01T12:00:00中间带个T前端new Date(2025-06-01T12:00:00)在某些浏览器可能OK但如果你前端用组件库的时间格式化函数识别不了带T的格式就会显示Invalid Date。解决办法是在application.yml里统一配置时间格式spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8但这里有个坑是这个配置只对java.util.Date生效对LocalDateTime不生效。如果你实体用的是LocalDateTime需要额外引入jackson-datatype-jsr310依赖SpringBoot 2.x已经自带了并在配置里加spring: jackson: serialization: write-dates-as-timestamps: false或者更省事的方式在实体类的日期字段上用JsonFormat(pattern yyyy-MM-dd HH:mm:ss, timezone GMT8)一个个指定。我实际项目里就是所有数据库时间字段都用LocalDateTimeJsonFormat统一标注虽然啰嗦了一点但胜在直观不会出错。4.3 图片上传路径配置的经典大坑宠物服务平台的宠物头像、服务项目封面、资讯配图都涉及文件上传。SpringBoot做上传接口本身很顺畅接收MultipartFile然后transferTo保存到本地指定目录就完了。但接下来前端访问图片时问题来了图片保存到了D:/pet-platform/upload/avatar/20250601/xxx.jpg前端怎么通过URL访问到它办法是做一个静态资源映射把/api/upload/**的请求映射到本地磁盘目录Configuration public class WebResourceConfig implements WebMvcConfigurer { Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/api/upload/**) .addResourceLocations(file:D:/pet-platform/upload/); } }这里我踩过一个隐藏坑路径里的file:协议前缀不能丢否则映射不生效另外路径末尾的反斜杠/也必须带上导致我排查了很久。上传后的图片地址存数据库时我习惯只存相对路径/api/upload/avatar/20250601/xxx.jpg访问时前端拼上站点域名。这样部署到Linux服务器时只需要改实体类对应目录映射配置就行数据库里的数据完全不用动。5. 前后端分离项目的部署上车指南从打包到Nginx反向代理前面所有开发工作完成后最终要让这个项目跑在服务器上而不是只停留在本地IDE里。部署环节是很多人的知识盲区因为本地跑通和服务器跑通之间有大量环境性问题要处理。5.1 SpringBoot后端打包与配置文件分离后端打包前要做两件事检查application.yml里的数据库连接、Redis连接、文件上传路径等配置是否为服务器环境预留了调整空间。我习惯把配置文件拆成三份application.yml公共配置服务端口、Jackson格式等application-dev.yml本地开发环境配置application-prod.yml生产环境配置启动时用--spring.profiles.activeprod指定使用哪套配置。这样本地开发用dev部署用prod互不干扰。打包命令在项目根目录执行mvn clean package -Dmaven.test.skiptrue执行完在target/目录下生成pet-platform-0.0.1-SNAPSHOT.jar。用java -jar pet-platform-0.0.1-SNAPSHOT.jar --spring.profiles.activeprod启动。在服务器上为了管理方便我写了简单的Shell脚本做启动、停止、重启本质就是记录PID然后kill -9。5.2 Vue前端打包与Nginx配置前端在vue.config.js里配置了开发环境的proxy代理把/api请求转发到后端8081端口。但打包上线后devServer的proxy不生效了需要靠Nginx做真正的代理转发。前端打包npm run build生成dist/目录把dist目录下的静态文件上传到服务器Nginx的/usr/share/nginx/html/pet-platform/目录下面。Nginx配置的关键块server { listen 80; server_name your-domain.com; location / { root /usr/share/nginx/html/pet-platform; index index.html; try_files $uri $uri/ /index.html; # 解决Vue Router history模式刷新404问题 } location /api/ { proxy_pass http://127.0.0.1:8081; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }这里try_files $uri $uri/ /index.html是Vue Router使用history模式即URL中没有**#**时必需的配置。如果不加这行用户在/pet/list页面刷新一下Nginx会去找服务器上根本不存在的/pet/list文件返回404。我第一次部署时就栽在这上面前端页面点击路由正常一刷新就404后来查了Nginx文档才明白是history模式需要同步到Nginx配置。5.3 部署后的接口安全加固不止是登录鉴权项目跑起来只是第一步真正上线前有几项安全加固我认为不能省。第一密码传输。虽然数据库存的是BCrypt加密后的密码但如果前端通过HTTP明文传输密码中间人可以截获。我建议在Nginx层启用HTTPS用Lets Encrypt免费证书至少保证传输链路加密。第二接口防刷。登录接口如果不做限制容易被脚本暴力破解。我用了简单的Redis计数器同一个IP每分钟最多请求登录接口5次超过就返回“操作过于频繁”。这个逻辑写在SpringBoot的拦截器或者AOP切面里很实用。第三参数校验。后端接口接收的参数要做好校验尤其是用户传入的id和petId必须验证归属权。比如用户A登录了如果他直接改请求体里的petId来提交一只不属于他的宠物后端不做校验就会产生脏数据。我统一在Service层的最前面做“查询实体 → 判断是否存在 → 判断归属者”三步校验宁可多写几行代码也不要让接口裸奔。第四HTML富文本内容存储常见的XSS问题。发布文章时如果用户提交的HTML内容里包含script标签前端解析时会执行脚本形成存储型XSS。我参照社区里常见的做法写了一个全局过滤器对请求参数做转义处理把替换为lt;、替换为gt;等但要注意富文本场景会误伤正常的HTML标签。更稳妥的方案是后端用Jsoup库进行白名单过滤只允许p、img、strong等安全标签存在其余一律剔除。6. 关于性能优化和后续扩展说说我实操中的具体取舍这个项目做完后我又盘了盘哪些地方可以优化。说实话毕设和小型实战项目不需要追求极致的并发和微服务但有些优化做起来成本低、收益直观值得动手。MySQL慢查询优化是我第一个看的。预约列表页如果数据量涨到几万条没有索引的话全表扫描会很慢。我在appointment表的user_id和appointment_date字段上建了普通索引查询用户自己的预约时性能立竿见影。另外订单表的order_no字段必须建唯一索引既保证业务唯一性又能加速按订单号查找。Redis缓存这块我把首页的轮播图数据、热门文章列表缓存到Redis里缓存时间5分钟过期后从数据库重新加载并回填。整体代码量不大但接口响应时间从120ms降到20ms左右体验提升明显。缓存更新策略上后台编辑文章内容或上下架服务项目时手动调用一次删除缓存的方法这样用户端下一次请求就会重新加载最新数据。后续如果要扩展功能我的建议是按“基础模块—增强模块”的思路来先保证用户、宠物档案、预约、订单、文章评论这几个核心模块的稳定再考虑接入宠物寄养日历、在线支付、微信小程序端。小程序端和后端接口重用的成本并不高因为后端接口本来就是无状态的JWT鉴权前端换一套框架接同一套接口即可。文档和接口测试方面我维护了一份Swagger接口文档SpringBoot 2.7.x配合springfox-boot-starter3.0.0版本即可但要注意SpringBoot 2.6之后的PathPatternMatcher和springfox的路径匹配策略冲突需要在application.yml里设置spring.mvc.pathmatch.matching-strategyant_path_matcher。这个坑也是我查了半天的配置前接口文档直接白屏加上配置后秒出所有接口列表。7. 我做完这个项目后建议你重点关注的三件事项目收工后我复盘了一下如果要给后面做类似宠物服务平台或SpringBoot前后端分离项目的朋友一些建议核心就三条。第一状态流转一定要集中管理。预约、订单这些核心业务都有生命周期把状态判断的逻辑集中在一个Service类里管理前端展示的按钮根据状态动态渲染。宁可前期多设计几个状态枚举也不要图省事用零散的if-else分散在Controller、Service各处。等项目做到后期你会发现状态流转清晰是整个系统可维护性的最大保障。第二统一响应体和全局异常处理必须在一开始就建好。我见过很多项目R类写到一半有的是返回data有的是直接返回一个Map前后端对接时所有人都在问“这个接口返回什么结构”。从第一个接口开始就返回R.success(data)错误时抛BusinessException全局捕获后返回R.error(code, msg)这个习惯能省掉后续90%的接口联调摩擦。第三安全相关的配置不要留到最后。大家很容易把跨域、密码加密、ThreadLocal清理、静态资源映射这些问题当作“旁枝末节”放到最后。真到项目联调阶段这些问题会一次性涌出来排查起来非常崩溃。我后面接类似项目时都是在一开始搭建项目骨架时就把跨域配置、JWT拦截器、全局异常处理、统一响应体全部配好后面每写一个接口都是在既定框架里填业务代码体验和在烂代码上打补丁是完全两回事。如果你正准备动手做类似的项目希望这篇记录能帮你避开我已经踩过的坑少走几步弯路。做完一个完整项目最大的意义不是代码量写了多少而是从头到尾把“用户状态、业务单据、状态流转、接口协议、部署方案”这一整条链路跑通一遍。这份经验在只看理论知识点的时候是永远学不到的。