SpringBoot+Vue3同城上门喂遛宠物系统实战解析

养过大型犬的朋友应该都有过这种体验出差三天家里狗子快把沙发拆了。约朋友上门帮忙吧欠人情不说人家也不一定有时间找家政保洁吧人家根本不接遛狗这种活。我当时接触到的宠物社区里类似的求助信息几乎每天都有但靠人肉匹配效率实在太低了——这大概就是同城上门喂遛宠物系统最朴素的出发点。后来我自己上手做了这么一套系统技术栈选的是Java SpringBoot Vue3 MyBatis数据库用MySQL前后端彻底分离。整套源码从需求拆解到上线部署都走了一遍过程中踩了不少坑这篇文章算是把我认为最有价值的落地经验整理出来包括业务模块怎么划分、表结构怎么设计订单状态机、为什么下单一定得加事务和唯一索引、Vue3这边怎么跟后端对齐状态、以及上线前要注意的边界问题。如果你正准备做同城服务、上门服务、预约类系统或者只是想看SpringBoot Vue3 MyBatis这套组合在真实项目中怎么配合这篇文章应该能帮你省掉不少试错时间。1. 为什么同城喂遛能成这个系统到底在解决什么匹配问题1.1 用户两端的需求拆解任何同城服务类系统本质都是撮合交易。喂遛宠物看似简单但它的特殊性在于供给端和需求端都极度分散且信任门槛很高。需求端是宠物主。这类人的典型场景是临时出差、加班太晚回不了家、或者宠物需要按时喂药、按时遛放。他们对服务的要求不是“把狗带出去走一圈”这么简单而是希望服务者能按宠物习惯操作——几点喂饭、遛多久、遇人要不要避开、狗粮放在哪、猫咪胆小该不该强行互动。这些细节会直接影响宠物主对平台的信任。供给端是服务者。他们可能是喜欢宠物的学生、自由职业者、退休阿姨也可能是在宠物店兼职的店员。他们的诉求也很明确接单方便、价格透明、时间自由、并且不会因为服务纠纷被平台无理由扣钱。所以这个系统表面上做的是“下单-接单-完成-评价”实际上做的是把宠物主的知识经验喂养习惯和服务者的时间技能高效匹配起来。这个认知直接决定了后续的表设计宠物档案必须是结构化且可编辑的订单必须冗余一份当时的服务信息评价和投诉必须留痕。1.2 业务闭环从下单到评价的完整链路我梳理出的最小业务闭环是这样的宠物主注册登录完善宠物档案品种、年龄、喂食习惯、遛放偏好、注意事项浏览同城服务者列表按区域、评分、服务类型筛选选定服务者后选择服务日期和时段提交订单服务者端看到待接单订单决定接单或拒绝接单后宠物主可以在线查看服务时间服务者按约定上门完成任务服务完成后双方互相评价订单进入历史记录你可能会问为什么不是“宠物主直接选时间下单平台自动分配服务者”因为喂遛服务不是打车每个宠物对服务者的要求不同有些猫怕生人有些狗力气大需要壮一点的人来牵。必须给人选择的余地让宠物主手动挑服务者成功率反而更高。1.3 系统边界MVP先砍掉哪些功能做需求的时候最容易失控。我一开始也想把在线支付、实时定位、后台管理系统、优惠券、会员体系全做进去后来被现实劝退了。MVP阶段的取舍是保留完整的订单闭环和双向评价砍掉支付线下交易、砍掉实时定位追踪服务开始后手动确认、砍掉平台客服工单、砍掉优惠券。理由很简单这些功能不影响核心流程跑通而且支付涉及商户资质定位涉及地图服务key和服务器成本这些都可以在验证需求之后再加。提示如果你也在做类似的同城服务类系统记住一个原则——先证明有人愿意用再考虑怎么赚钱。MVP的“砍”不是功能缺失而是战略选择。2. 技术选型复盘SpringBootVue3MyBatis这套组合为什么合适2.1 Java后端为什么选SpringBoot而不是其他这里完全没有贬低其他语言的意思但Java在“同城服务”这个场景里确实有优势。首先是生态成熟Spring全家桶对事务、权限、定时任务、消息队列都有现成方案其次是做这类项目的团队里Java开发者的占比太高了招人或者后续接手都方便。具体到SpringBoot我比较看重的是自动配置和起步依赖。一个新项目从零到能跑起来写一个Controller加一个Mapper大概十分钟就够了。它不像传统SSM那样需要我手动装配一堆XML配置也不需要关心Tomcat怎么部署直接打成jar包就能跑。在这个系统里SpringBoot承担的工作可以拆成几块Spring Web提供RESTful API接口Spring Validation处理请求参数校验Spring AOP实现日志记录和部分鉴权逻辑Spring Task处理定时任务比如超时未支付订单自动关闭MyBatis Starter数据库访问层集成2.2 Vue3组合式API的取舍前端我选了Vue3而不是Vue2核心原因是组合式API对复杂交互的代码组织更友好。这个系统里有宠物主端和服务者端两种视角同一个组件的逻辑复用诉求很强比如订单列表两个角色都会用到但操作按钮完全不同。用Vue2的Options API写我需要把data、methods、computed、watch分开一个页面反复切来切去用Vue3的setup语法糖我可以在一个函数里把状态和逻辑挨着写再通过自定义组合式函数把订单相关逻辑抽出来复用。打个比方Options API像一个按菜谱步骤操作的厨房每个环节分得很清但东西散落各处组合式API更像一个开放式厨房我把切菜、炒菜、装盘的全流程放在一个操作台上想复用直接整段搬走。UI组件库方面项目用了Element Plus。它对Vue3支持比较完善表格、表单、对话框、时间选择器这些后台管理常用的组件都覆盖了开发效率比手写样式高很多。如果你的页面偏C端展示、对视觉要求较高可以考虑TailwindCSS或者Naive UI但做管理后台和简易C端Element Plus足够。2.3 MyBatis和MySQL复杂查询与事务控制的平衡为什么用MyBatis而不是JPA我的理由其实写在标题里了MyBatis对SQL有完全的控制权。这个系统的查询条件非常灵活——订单列表要按状态、日期、服务类型、城市、关键字组合筛选宠物主和服务者的订单列表甚至需要动态拼接不同的where条件。用MyBatis的XML文件写动态SQL改起来直接、出问题时定位也快。MySQL则负责稳定的数据落地。订单状态机、用户余额、宠物档案这些核心数据都需要强一致性和事务控制MySQL的InnoDB引擎在这个场景下成熟可靠。唯一需要留意的版本是8.0以上对JSON类型和窗口函数的支持更好我建议新项目直接用8.0。3. 表结构与订单状态机喂遛业务最核心的“地基”3.1 核心表关系用户-宠物-服务者-订单整个系统我设计了六张核心表互相之间的关联关系相对清晰表名用途关键字段user用户表区分宠物主和服务者角色id, phone, password, role, nickname, avatar, area_codepet宠物档案表id, user_id, name, species, breed, weight, age_scope, personality, feeding_note, walk_rulesservice_provider服务者信息表id, user_id, service_type, price_per_hour, available_time, rating, review_count, skill_tagsorder_info订单主表id, order_no, user_id, pet_id, provider_id, service_date, service_slot, status, amount, address, notereview评价表id, order_id, from_user_id, to_provider_id, rating, contentfavorite收藏表可选id, user_id, provider_iduser表里我用role字段区分角色0是宠物主1是服务者。一个账号是否可以同时是两种角色理论上可以但为了简化权限逻辑MVP里我规定一个账号只能选一个角色后续如果有需要再支持角色切换。pet表是整个服务的“说明书”。我把喂养习惯、遛放规则、惧怕什么、需不需要戴嘴套这些都做了字段甚至文本类型的note字段宠物主填写越详细服务者的操作越有依据纠纷越少。真实项目里这块甚至可以做成动态表单让宠物主按模板填写减少文字描述的随意性。3.2 订单状态机从待支付到已完成的状态流转订单表里最重要的是status字段它驱动了整个系统的所有交互。我定义的状态如下0-待支付下单未付款 1-待接单已付款/确认下单等待服务者接单 2-已接单服务者确认接受 3-服务中服务者点击开始服务 4-已完成服务者点击完成 5-已取消宠物主或服务者取消 6-售后中已完成但双方产生纠纷这里有一个关键设计决策待支付和待接单是分开的。为什么不能下单直接进入待接单因为线下交易场景下如果宠物主没付款就占用了服务者一个时段服务者一打开看到三四个订单但都是“挂了没付钱”的体验非常差。我要求下单后30分钟内必须支付否则定时任务自动把订单状态改为已取消并释放时段。状态流转的合法性我做了状态机的约束后端在更新订单时会校验当前状态是否允许目标状态。比如服务者不能在待支付状态下接单宠物主不能在服务中状态随意取消。这个校验我放在Service层做了统一处理而不是在Controller里做一层防止绕过某个接口直接改状态。3.3 表设计中的三个防坑细节第一个坑是订单表必须冗余快照字段。宠物主可能在下单后修改了宠物档案如果把喂养习惯直接关联pet表服务者看到的信息就可能和下单时的信息不一致。我在订单表里冗余了pet_name、pet_breed、feeding_note快照字段下单那一刻把宠物档案复制一份历史订单永远保留下单时的摘要。第二个坑是时间段必须原子化。同城喂遛服务存在明确的档期冲突同一个服务者不能在同一时间接两单。我在订单表加了唯一索引provider_id, service_date, service_slotservice_slot是预先定义好的时段比如上午9:00-11:00、下午14:00-16:00。这样从数据库层就直接挡住了重复接单比在Service层用锁更保险。第三个坑是逻辑删除优先。用户注销、宠物档案删除这类操作我建议都采用逻辑删除deleted字段标记而不是物理删除。原因很简单订单表关联了历史数据如果你物理删除了宠物或用户记录历史订单的关联就会断裂后续对账、纠纷仲裁都没有依据。4. 后端实现的关键细节认证、事务锁与动态SQL4.1 JWT登录与接口鉴权认证选型上我用了JWTJSON Web Token方式主要因为它天然适合前后端分离。服务器不需要保存会话状态用户登录成功后后端签发一个token返回给前端前端在后续请求的Header里带上Authorization字段后端通过拦截器解析token得到用户信息。关键实现里需要注意两点一是拦截器只负责解析和放行具体的权限判断应该在代码里做。我写了一个简单的拦截器从请求头里取出token解析出userId放入ThreadLocal方便后续Service层获取。如果token缺失或过期直接返回401。角色判断则在需要区分宠物主和服务者的接口里通过注解或代码判断。二是token要设置合理的过期时间。这个系统面对的是低频使用的场景用户可能一周才打开一次app/网页如果token设置30分钟过期会让用户体验极其糟糕。我设置了7天有效每次请求时向前滑动续期。安全性上牺牲了一点但对这类非金融类业务来说体验优先是可接受的。public class LoginInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token request.getHeader(Authorization); if (StringUtils.isBlank(token)) { throw new BusinessException(401, 未登录); } // 解析token设置用户上下文 Long userId JwtUtil.parseToken(token); UserContext.set(userId); return true; } }4.2 下单接口事务唯一索引解决并发重复接单下单是整个系统里最容易出并发问题的接口。想象一下这个场景服务者在同一时间段被两个宠物主同时下单服务者自己也很纠结手一抖两单都接了。如果服务端不做并发控制就会导致一个服务者同时接了两个重叠的订单。我采用的方案是数据库唯一索引 事务组合。下单时先在一个事务里执行校验订单参数宠物主信息、宠物档案、服务者信息必须存在且有效校验服务者该时段是否已被占用——这条不是简单的select而是直接尝试insert一条订单记录插入订单时若唯一索引provider_id, service_date, service_slot冲突数据库抛异常事务回滚这一段代码看起来平平无奇但它把并发问题从“代码层面解决”变成了“数据库层面兜底”。即使两个请求同时进来只有一个能插入成功另一个必然因唯一索引冲突而失败事务直接回滚。Override Transactional(rollbackFor Exception.class) public Long createOrder(CreateOrderRequest request) { // 1. 参数校验 validateOrderParams(request); // 2. 检查服务者和宠物信息 Pet pet petMapper.selectById(request.getPetId()); ServiceProvider provider providerMapper.selectByUserId(request.getProviderId()); // 3. 构建订单并插入 OrderInfo order buildOrder(pet, provider, request); try { orderMapper.insert(order); } catch (DuplicateKeyException e) { throw new BusinessException(该服务者当前时段已被占用请换个时段试试); } // 4. 返回订单号 return order.getId(); }4.3 MyBatis动态SQL处理订单筛选与分页订单列表是查询最复杂的接口因为筛选条件完全是动态的。宠物主视角可能想看“待接单的订单”“本月的历史订单”“某个服务者的订单”服务者视角可能想看“某一天的订单”“某个状态的所有订单”。如果用Java代码拼SQL业务一复杂就是灾难。MyBatis的XML动态SQL帮了大忙。它的where标签可以自动去除多余的和ANDif标签根据条件拼接查询片段。我写了一个通用的订单查询Mapper把用户类型、状态、日期范围、服务者ID、宠物主ID全都作为可选条件传入一个Query对象返回分页数据。分页这里我用了MyBatis的PageHelper插件基本原理是自动拦截SQL并在末尾追加LIMIT。需要注意的一个坑是PageHelper分页时如果有多表联查或者自定义返回字段一定要在查询之前设置PageHelper.startPage且只对紧接着的第一条查询生效否则会有数据错乱的问题。另外如果你做了嵌套结果映射resultMap的collectionPageHelper只对主查询做物理分页子查询的结果集不受分页影响这个要记住。4.4 时间字段的序列化处理这个坑值得单独拿出来讲前后端时间对接。后端Java用了LocalDateTimeMyBatis可以正常映射到MySQL的datetime类型但到了JSON序列化这里就出事了。默认的Jackson会把LocalDateTime序列化成一大串数组前端根本没法直接用。我统一做了两件事第一在application.yml里配置了全局时间格式spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8第二对前端提交的日期字符串在后端DTO里用DateTimeFormat注解明确指定格式避免因为毫秒级时间戳或者不同格式的字符串导致解析失败。实际使用中前端从下拉框选择的服务日期我统一用yyyy-MM-dd格式传回后端后端用LocalDate接收这样比用LocalDateTime更准——因为日期只需要精确到天时段是单独一个字段。避免把“2025-06-20 00:00:00”这种时间当业务时间存储后续做分组统计会出一堆边界问题。5. Vue3前端如何把订单状态“管”起来5.1 路由与菜单结构前端项目的目录规划我遵循了“按模块划分”的思路。路由分三层结构登录注册页、宠物主端主框架、服务者端主框架。两个角色的菜单不同所以我在布局组件里根据当前用户角色动态渲染侧边栏。路由示例const routes [ { path: /login, component: Login }, { path: /pet-owner, component: Layout, meta: { role: PET_OWNER }, children: [ { path: providers, component: ProviderList }, { path: pets, component: PetManage }, { path: orders, component: OrderList } ] }, { path: /provider, component: Layout, meta: { role: PROVIDER }, children: [ { path: orders, component: ProviderOrderList }, { path: schedule, component: ProviderSchedule } ] } ]这里用了路由元信息meta.role来标记每个路由允许的角色再配合全局前置守卫做访问控制用户未登录跳转登录页登录了但访问了不属于自己角色的页面重定向到自己的首页。这样做比在每一个页面里写if判断要省事得多也避免漏判。5.2 Pinia存储用户角色与tokenVue3的状态管理我选了Pinia它是Vuex的官方替代方案API更简洁没有mutations这个概念直接改state就行。我建了一个user store保存token、用户基本信息、当前角色。Pinia在刷新页面后状态会丢失这是所有前端状态管理的通病。解决办法很简单把token存在localStorage页面刷新后读取localStorage再重新构建store状态。但要注意不要把所有用户信息都塞localStorage敏感信息尽量只存token用户信息每次进入系统时通过接口重新获取。// store/user.js export const useUserStore defineStore(user, { state: () ({ token: localStorage.getItem(token) || , userInfo: null, role: localStorage.getItem(role) || }), actions: { async login(payload) { const res await api.login(payload); this.token res.data.token; this.role res.data.role; localStorage.setItem(token, this.token); localStorage.setItem(role, this.role); }, logout() { this.token ; this.userInfo null; this.role ; localStorage.clear(); router.push(/login); } } });5.3 Axios拦截器与页面状态对齐Axios拦截器是前后端对接的“中间件”它统一处理三件事请求头注入token、响应中统一处理业务错误码、401跳转登录。后端返回格式我统一用{ code: 200, message: success, data: {} }所以拦截器里判断code而不是HTTP状态码这是很多前后端协作项目里最容易产生分歧的地方。我强烈建议HTTP状态码只表示传输层的成功失败业务层的成功失败一律用code字段。前后端都遵循这个约定之后联调时“接口返回了500但页面没提示”这类问题就直接消失了。还有一个细节后端返回的订单状态是数字前端需要用枚举表来映射成中文显示。这个映射关系如果前后端各维护一份时间久了必然对不上。我建议后端在util包提供一个OrderStatusEnum类最终通过字典接口下发前端只需要渲染前查一次字典。5.4 接单交互中的轮询与状态刷新服务者端的订单列表有个很实际的问题宠物主下单后服务者端需要实时看到新订单。全上WebSocket对MVP来说成本偏高我采用了简单的轮询方案——服务者订单列表页每30秒调一次查询接口把status非终态待支付、待接单、已接单、服务中的订单拉取回来前端合并去重后刷新列表。这个方案不是最优的实时方案但胜在简单可靠。如果你希望做真正的实时推送可以后续在系统里集成WebSocket或者Server-Sent Events把“有新订单”事件推送给服务者端。6. 从Demo到上线部署、索引与待扩展能力6.1 打包部署前端Nginx与后端jar前后端分离项目部署上我的习惯做法是前端打包成静态文件交给Nginx后端SpringBoot打成jar包通过systemd守护运行。Nginx里两个核心配置一是root指向前端dist目录二是/api路径代理到后端的SpringBoot服务。location /api/ { proxy_pass http://127.0.0.1:8080/api/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; }部署时有一个常见坑前端静态页面的路由模式。如果用history模式用户在浏览器直接刷新某个子路由页面Nginx就会返回404。需要加一行try_files配置让所有非静态文件请求都回退到index.html。location / { root /var/www/pet-park/dist; try_files $uri $uri/ /index.html; }另外环境配置一定要分dev和prod两份数据库连接、Redis地址、日志级别分开管理。我见过很多人把测试库密码打包进生产jar才慌慌张张四处交代这种事真的不能发生在正式项目里。6.2 上线前必加的索引与约束项目在开发环境跑得很欢数据量一上来就卡大部分问题出在索引缺失。我上线前梳理了一遍所有查询场景的where条件和排序字段加了以下索引order_info表(provider_id, service_date, service_slot) 唯一索引防并发重复接单order_info表(user_id, status) 普通索引服务宠物主端订单列表order_info表(order_no) 唯一索引按订单号查询pet表(user_id) 普通索引查询用户宠物列表service_provider表(area_code, service_type) 复合索引服务者列表筛选索引不是越多越好而是要跟查询匹配。我在开发中发现有人不加区分地给所有字段加索引结果写入性能明显变慢这就是过度索引的教训。一般先看慢查询日志再结合业务场景补索引比拍脑袋建索引靠谱得多。6.3 地图/支付/消息推送的扩展预留最后聊聊这个系统上线后可以怎么扩展也算是我踩过需求坑之后的反思地图服务。同城服务天然需要距离筛选和定位。在服务者表预留area_code字段是最基础的进阶做法是接入地图服务让宠物主按距离排序服务者。实际开发中建议用WebService API来算两点间的驾车/步行距离而不要直接在前端暴露key。在线支付。MVP阶段我可以接受线下交易但一旦单量上来没有支付流水就是一笔糊涂账。我预留了payment表和order_info.payment_status字段后续接微信支付、支付宝只需要加一个支付渠道表和回调通知处理不需要动订单主流程。消息推送。我前面说的30秒轮询是个临时方案规模化后还是要上真正的推送。小程序场景用订阅消息App场景用厂商推送通道Web场景用WebSocket或SSE。扩展的时候注意推送内容要包含订单号和服务地址接收者点击消息后要能直接跳到对应的订单详情页。我个人实测下来这个同城喂遛宠物系统从设计到跑通大约花了两周真正耗时的是反复打磨状态机和并发控制。如果重来一次我会在需求阶段就把状态机画得再细一些把哪些状态允许取消、取消后押金怎么退、服务超时谁来标记等问题一次想清楚这些业务细节不提前锁死写代码的时候就会一直返工。你如果也要做类似的预约类系统希望这篇笔记能帮你少走几步弯路。