前阵子帮本地几家汽车改装店做了一套同城维修系统的订单管理后端技术栈锁定 Java从需求梳理到源码落地前后折腾了两个月。不少同行看到 demo 后跑来问这套系统的源码思路今天干脆把整个设计和实现拆开聊透。所谓“同城维修系统”核心是把汽车改装店的施工档期、维修能力、技师排班和同城车主的预约需求拉到同一个平台上。车主端能按距离找店、看服务项目、下单预约门店端能管工单、派技师、记进度后台还要能处理会员储值、套餐核销和结算。如果你正打算用 Java 做一套这类带 LBS 属性的服务预约系统或者准备拿它当项目经验写进简历这篇内容应该能省你不少弯路。1. 汽车改装同城维修系统的需求解构1.1 改装维修行业线上化的核心痛点在哪里汽车改装维修和普通保养不太一样改装项目客单价高、施工周期长、技术要求差异大。比如一套包围套件安装和一次发动机程序调校完全不是一回事。很多改装店不缺手艺缺的是把订单、车辆信息、施工进度管起来的手段。过去靠微信聊天记录接单技师做完活口头汇报老板根本不知道哪台车在哪个工位、谁负责、进行到哪一步。车主侧的问题同样明显。改装不是天天有需求车主第一次到店往往不熟悉施工流程不知道要准备什么、大概要多久、费用包含哪些项。要是门店在十几公里外车扔过去两三天来回取送都是成本。所以“同城”这个概念不是营销噱头它直接决定了车主愿不愿意把车交给这家店。这个系统要解决的不只是“线上接单”而是把整个服务链路串起来。车主提交车辆信息和改装意向门店确认施工方案和报价技师接单后按节点更新进度完工后车主验收付款。每一环都需要明确的状态记录这也是 Java 这类强类型语言比较适合做这类业务的原因——状态流转可以用枚举和状态机严格约束源码层面不容易写出脏数据。1.2 同城模式下的角色与流程梳理系统的角色可以拆成四类车主、门店端员工、平台运营、系统管理员。车主通过微信小程序或者 App 下单门店员工包括店长和技师店长有权接单派工和改价技师只负责更新施工进度和上传完工照片。平台运营负责审核门店入驻资质管理员管全量配置。主流程并不复杂车主按距离和擅长项目筛选门店选择服务项目后填写车辆档案品牌、型号、年款、改装需求描述提交预约请求。门店店长收到待确认订单后先根据车辆信息判断能不能做能做的报出预估工时和报价车主确认后订单进入施工队列。技师领取工单后在系统里把状态从“待施工”推进到“施工中”再到“待验收”。车主确认完工订单闭环门店发起结算。这里面有一个细节经常被忽略改装项目的报价往往不是一口价而是“预估报价实际结算”。比如换避震拆开后发现塔顶老化需要一并更换费用就会变。系统里必须支持店长在施工中追加费用项目车主端实时收到增项确认否则等验收时突然加价客诉率一定直线上升。1.3 需求边界与MVP版本划定接这种项目最忌讳一上来就铺大而全的功能。同城维修系统的 MVP 至少要砍掉商城、社区、积分等非核心模块保留的基础功能列表大概是门店管理入驻审核、营业时间、服务项目配置车辆档案支持一个车主绑定多台车记录改装历史预约拆单一个预约单可包含多个改装/维修项目工单流转待确认、待施工、施工中、待验收、已完成、已取消技师指派支持店长手动派单也支持抢单模式增项确认施工中临时增加维修项目和费用结算与核销支持到店付和线上预付定金第一版把这几条跑通门店才会真正愿意用。你永远不要试图在第一版就做出一个车主天天逛的社区那类产品属于运营驱动和工具型系统是两种玩法。2. Java技术选型与项目架构设计2.1 为什么这套系统用 Java 写更稳选型的时候不是没考虑过 Node.js 和 Go。但我最终选择了 Java 生态的 Spring Boot 3 MyBatis-Plus原因很务实第一团队里大家最熟的技术栈就是 Java第二这类业务系统后期一定会接支付、短信、地图、对象存储这些第三方 SDKJava 的生态最全遇到问题能查到的资料最多第三客户方通常希望后续能自己维护Java 在二三线城市的用人市场依然比 Go 好招人。Java 在汽车后市场这种低频高价值场景里的另一个优势是稳定性和事务能力。改装订单涉及金额变更、库存扣减、工单状态更新一个请求里往往要写好几张表Spring 的声明式事务可以很好地保证原子性。换作脚本语言得靠开发者自己小心维护事务边界容易在退款和增项这种场景上出事故。版本上我选了 Spring Boot 3.2.x要求 JDK 17。没必要追 Spring Boot 3.3 或 3.4稳定压倒一切。JDK 17 是 LTS 版本虚拟线程在 JDK 21 才算成熟但这种 IO 密集业务并发量并没有大到需要用虚拟线程17 完全够用。2.2 后端分层架构与依赖模块划分工程按 Maven 多模块拆父 pom 只管理依赖版本。源码目录按业务模块划分而不是按技术分层划分这一点对后期维护特别重要repair-system/ ├── repair-common // 通用工具、常量、异常定义 ├── repair-system-api // Controller层 DTO ├── repair-service // 业务逻辑层 ├── repair-dao // MyBatis-Plus Mapper与Entity ├── repair-job // 定时任务模块 └── repair-admin // 后台管理端接口项目不算大所以没有引入微服务和分布式事务那属于过度设计。单体应用加上 Redis 缓存足够支撑一家城市几十家门店的订单量。真正的核心是把模块边界划清楚避免 Controller 里写业务 SQL、Service 互相调用成环这些坏味道在单体项目里比在微服务里更容易滋生。依赖选型上有几样值得单独列出来持久层MyBatis-Plus简单 CRUD 不用写 XML复杂统计SQL自己写缓存Redis门店列表缓存、验证码存储、分布式锁接口文档Knife4j基于 OpenAPI 3调试联调效率高工具库Hutool处理日期、ID 生成、Bean 拷贝这类杂活对象存储MinIO 或阿里云 OSS存放施工照片和证件照2.3 数据库设计的高频表结构数据表是整个系统最耗心力的部分我最终落地的核心表包括门店表、门店服务项目表、技师表、车辆档案表、预约单表、工单表、工单项目明细表、增项记录表、优惠券表、订单支付流水表。一张工单对应多个项目明细这是必须拆开的因为不同项目的施工工时不同、状态推进可能不同步。拿预约单表来说关键字段大致是CREATE TABLE repair_order ( id bigint NOT NULL COMMENT 主键ID, order_no varchar(32) NOT NULL COMMENT 订单编号, user_id bigint NOT NULL COMMENT 车主用户ID, shop_id bigint NOT NULL COMMENT 门店ID, car_id bigint NOT NULL COMMENT 车辆档案ID, status tinyint NOT NULL COMMENT 状态: 10待确认 20待施工 30施工中 40待验收 50已完成 60已取消, appoint_time datetime DEFAULT NULL COMMENT 期望到店时间, total_amount decimal(10,2) NOT NULL DEFAULT 0.00 COMMENT 预估总价, settle_amount decimal(10,2) NOT NULL DEFAULT 0.00 COMMENT 结算总价, remark varchar(500) DEFAULT NULL COMMENT 车主备注, create_time datetime NOT NULL, update_time datetime NOT NULL, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no), KEY idx_shop_status (shop_id, status), KEY idx_user_status (user_id, status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT预约订单表;订单号生成我用的是日期 随机序列没有用雪花算法原因很简单——单库单表场景下雪花算法带来的复杂度大于收益。生成的订单号形如20250112103000123456前面是年月日时分秒后面六位随机数再对订单号做唯一索引防重。3. 核心源码实现业务闭环的关键代码解析3.1 基于JWT的多角色登录与权限控制系统里有车主、店长、技师、运营四种角色共用同一套用户体系。登录认证我选用 JWT 而不是传统 Session原因是门店端技师可能同时在 PC 浏览器和手机小程序上登录JWT 天然支持多端无状态认证不需要额外维护 Session 同步。JWT 令牌在登录成功后放进 Rediskey 为login:token:{userId}:{clientType}value 为令牌字符串过期时间跟令牌保持一致。每次请求经过拦截器时除了校验签名还要校验 Redis 里存的令牌和当前令牌是否一致。这样做的目的是如果用户修改密码或者被管理员禁用可以直接删掉 Redis key 强制令牌失效弥补了纯 JWT 不好主动失效的短板。权限上最初想用 Spring Security Sa-Token后来发现四五个角色、二十来个接口实在没必要引一整套安全框架。我直接自定义了一个RequireRole注解配合拦截器实现Target({ElementType.METHOD, ElementType.TYPE}) Retention(RetentionPolicy.RUNTIME) public interface RequireRole { String[] value(); }然后在拦截器中取出当前登录用户角色做比对不匹配直接抛 403。这套轻权方案在源码层面更容易读懂新人接手也看得明白。3.2 门店服务项目和技师派单逻辑设计每家门店能做的改装项目差异很大有的专精底盘和避震有的擅长动力程序有的只做外观和内饰。服务项目采用两级目录结构一级类目如“悬挂系统”“动力系统”“外观套件”二级是具体服务项比如“KW 避震安装调试”“一阶程序写入”。门店入驻时从平台标准服务目录中勾选自己能做的项并设置基础工时费。技师和门店是多对一关系但一位技师在不同门店之间可能流动所以设计成技师表里冗余了当前归属门店 ID加一个可用的兼职门店 ID 列表用逗号分隔存入冗余字段。查询门店技师列表时直接按当前归属门店查兼职场景再单独开接口处理避免复杂的关联关系影响主流程查询性能。派单逻辑采用了“店长派单为主、技师抢单为辅”的模式。这个决策来自业务走访改装店老板普遍希望自己控制施工节奏不希望技师各自挑活。但有些单子利润低、耗时短比如换机油换刹车片店长忙不过来时希望技师能自己认领。派单接口的核心逻辑是更新工单技师 ID同时写入一条操作日志方便日后追溯是谁在什么时间点把单派给谁。3.3 订单状态机的严谨设计状态管理是最容易出 bug 的地方。我见过太多系统的订单状态更新直接写UPDATE repair_order SET status 5 WHERE id 1也不管原状态是什么。这种代码在产品初期看不出问题一旦并发请求上来或者定时任务逻辑有漏洞就会出现“已取消的订单被推进到施工中”这类灾难。解决方案是定义一个状态机校验器。工单的可流转路径用枚举约束每次更新状态前先做校验不允许的状态迁移直接抛异常。比如public enum OrderStatus { PENDING_CONFIRM(10, 待确认), PENDING_CONSTRUCTION(20, 待施工), UNDER_CONSTRUCTION(30, 施工中), PENDING_ACCEPTANCE(40, 待验收), COMPLETED(50, 已完成), CANCELED(60, 已取消); }那么在服务层更新状态时先通过OrderStateMachine.canTransform(from, to)判断。待确认订单只能去待施工或者已取消施工中订单只能去待验收或者已取消。针对异常迁移直接记录一条告警日志把所有可疑操作都留痕后面排查问题会轻松很多。这套设计后来接支付回调、退款流程时给我省了大力气状态脏乱差的问题基本绝迹。3.4 同城距离筛选与地图坐标处理“同城”不是简单按城市编码过滤而是基于地图半径筛选。车主当前位置通过微信小程序的wx.getLocation获取经纬度后端通过高德地图 Web 服务 API 逆地理编码确认城市再筛选该城市内正常营业的门店。计算门店距离用的是 Haversine 公式这个老牌算法在公里级距离下精度足够而且性能远好于调用地图 API 批量计算。封装成工具方法public static double calculateDistance(double lat1, double lng1, double lat2, double lng2) { double radLat1 Math.toRadians(lat1); double radLat2 Math.toRadians(lat2); double a radLat1 - radLat2; double b Math.toRadians(lng1) - Math.toRadians(lng2); double s 2 * Math.asin(Math.sqrt( Math.pow(Math.sin(a / 2), 2) Math.cos(radLat1) * Math.cos(radLat2) * Math.pow(Math.sin(b / 2), 2))); return s * 6371.0088; }6371.0088 是地球平均半径单位是公里。算出来的距离再按用户设置的筛选半径过滤默认 15 公里。门店数量多到几千家时在 SQL 里对每条记录都做一次距离计算不是不行但会慢。更优的做法是用 MySQL 的ST_Distance_Sphere函数或者直接上 Redis GEO。第一家店的总量级也就是一两百我先用 SQL 查出候选门店再在内存里算距离和排序单次百来条记录毫秒级完成就没必要引入额外的空间索引复杂度了。3.5 派工看板与施工照片上传的工程落地技师端的核心是派工看板。技师登录后第一眼看到的是当天工单列表按状态分组。源码里的一个关键点是用了 WebSocket 做状态实时推送店长把工单派给技师后技师端页面不需要手动刷新就能看到新工单。WebSocket 连接在网关层做鉴权连接地址带上登录后的 JWT 令牌服务端在握手拦截器里校验令牌合法性。施工照片上传我用的是 MinIO 兼容 S3 协议图片先压缩再上传。这个环节有个深刻的教训最初直接传原图一张施工照片动不动 8MB、10MB结果车主端加载照片墙时流量消耗巨大。后来在客户端先压缩到宽度 1920px、质量 80%再上传到对象存储同时服务端用 Thumbnailator 生成 400px 缩略图列表页只返回缩略图 URL点开才加载原图。改造后接口响应时间从 1.8 秒降到 400 毫秒以内。4. 并发预约、支付回调与消息通知的可靠性设计4.1 预约抢单场景下的并发控制门店热门技师的数量有限恰好遇到优惠活动时同一时段可能涌入大量预约请求。如果两台车预约同一个工位同一时间段并发请求同时读到剩余可约数量为 1就会造成超卖。这个问题的本质是“检查-扣减”不是原子操作。解决思路有两层。第一层数据库层面使用乐观锁在工位排期表加一个版本号字段更新时带上WHERE version ?受影响行数为 0 就说明冲突让用户重新选择时间。第二层使用 Redis 分布式锁把“查询空闲时段 写入预约”做成一个临界区锁的粒度是门店 ID 日期 工位 ID这样并发压力远没有大到需要引入 Redisson 的情况下用 Redis 的SETNX就已经能挡住大多数冲突。不过后来数据分析显示单店单日预约请求量峰值也就几百大多数时候根本到不了并发瓶颈。真正需要防的是用户重复点击提交按钮导致的重复单。我的解决办法简单粗暴前端按钮提交后置灰一秒后端在订单创建接口上加幂等性校验——同一个车主 ID 5 秒内不能重复创建预约单。4.2 支付回调的幂等处理与掉单补偿线上预付定金很常见车主先付 99 元定金锁定施工档期尾款到店付或者完工结算时一起支付。支付环节我接入的是微信支付 Native 支付车主端展示二维码用户扫码支付后微信服务器回调后端接口通知支付结果。支付回调的源码看似简单坑却非常多。第一回调接口收到通知后要先验证签名再把回调数据里的订单号跟本地数据库里的订单号比对订单金额也要完全匹配防止伪造回调。第二回调处理必须做幂等同一个订单微信可能回调多次服务端第一次处理成功后把状态置为“已支付”后续回调直接返回成功即可不能再执行一次加余额或改状态的操作。代码层面我用了SELECT ... FOR UPDATE锁住这笔订单记录确保同一时间只有一个线程在处理回调。掉单问题也是必须考虑的。用户扫码支付成功但网络异常微信回调没到达服务器订单状态卡在“待支付”。每天凌晨跑一个定时任务把超过 10 分钟未支付的订单发起主动查单调用微信支付查单接口如果已支付就触发补单流程。这套“被动回调 主动查单”的双保险机制上线后基本没再出现过线上支付了门店却不认账的客诉。4.3 服务进度通知与消息推送选型消息通知这里要区分站内信、小程序订阅消息和短信。技师更新工单状态到“施工中”时车主更希望收到一条微信小程序订阅消息提醒而不是打开 App 看进度。小程序订阅消息的难点在于需要用户主动授权而且一次性订阅只能推送一次。我的做法是在车主确认下单时引导用户授权多个订阅消息模板一次授权长期可用。服务端推送订阅消息可以直接调用微信接口没有引入消息队列。对这套系统的现实状况而言单量还没大到需要引入 RocketMQ 或 RabbitMQ用 Spring 自带的事件机制ApplicationEventPublisher解耦就足够了。工单状态更新后发布一个OrderStatusChangedEvent监听器负责调微信订阅消息接口。消息队列是应对高流量的中低流量系统引入它只会增加运维负担。5. 源码工程落地过程中的关键踩坑与优化记录5.1 统一异常处理是源码质量的保证接口联调阶段最让前后端崩溃的就是各写各的错误返回格式。有的接口报错返回{code: 500, message: 系统异常}有的直接返回{code: 500, msg: 内部错误}前端接一个接口要适配一套返回结构体验很糟糕。后来我在 common 模块里定义了一个统一的返回包装类RT包含 code、message、data 三个字段外加一个全局异常处理器。业务异常通过BizException抛出处理器统一捕获并转成业务错误码参数校验错误通过Validated注解自动处理未捕获的异常统一返回“系统开小差了请稍后重试”但完整堆栈打到日志里供排查。一个容易被忽视的细节是全局异常处理器要区分 HTTP 状态码和业务状态码。参数校验失败返回 HTTP 400未登录返回 401无权限返回 403但业务逻辑失败统一返回 HTTP 200只在业务 code 里标明错误类型。前端只拦截 HTTP 非 200 的响应而业务错误码走message提示这样逻辑才清晰。5.2 用策略模式干掉手续费计算和分账逻辑里的if-else改装的结算规则和普通维修还不一样。不同门店的结算模式不同有的是平台抽佣固定比例有的是按金额阶梯抽佣。一开始 CustomerController 里写了一大串if (type 1) ... else if (type 2)每次新增结算规则都要改主流程代码容易改错。后来重构为策略模式。定义一个手续费计算策略接口public interface FeeStrategy { int getType(); BigDecimal calculate(BigDecimal amount); }每种结算规则是一个策略实现类用 Spring 注入到MapString, FeeStrategy中。新增规则时只需要新增一个实现类不需要改动原有主流程。对应到刚入行时面试八股文里常问的“策略模式有什么好处”这次算是实实在在用上了。5.3 大字段与索引对列表接口的性能影响工单列表页最初加载特别慢查了半天原因居然是工单表里有一列photos用来存放以逗号分隔的施工图片 URL数据量一大后字段存储空间膨胀虽然列表页用不着这个字段但SELECT *还是把它查了出来拖慢了查询速度。优化有两个思路第一列表查询不查大字段只查需要的列这是最直接的第二把 photos 移到单独的附图表一张工单关联多条附件记录数据模型更规范。线上环境已经跑了一段时间再去大改表结构有风险所以我选用了第一方案把 Mapper 里的查询 SQL 全部改成显式写出需要返回的列杜绝SELECT *列表接口响应时间立刻下降了一截。用 MyBatis-Plus 的时候尤其要注意这个问题。它提供的lambdaQuery()默认是SELECT *没指定返回列时会把整行所有字段都查出来。后来我养成了习惯批量查询前先想清楚列表页真正需要展示哪些字段对应写出select(LambdaQueryWrapper.select(Entity::getId, Entity::getOrderNo))这类写法。5.4 数据库索引设计的实际取舍上线后运营反馈“我的工单”列表翻页越来越慢。执行EXPLAIN看了一下发现查询语句里WHERE user_id ? AND status ? ORDER BY create_time DESC但联合索引只建了user_id和status排序还在走 filesort。在这个场景下最优的联合索引是基于查询条件的最左匹配创建(user_id, status, create_time)这样条件过滤和排序都能命中索引不需要额外排序。这属于面试八股文里被嚼烂的联合索引最左前缀原则实际业务中仍然值得反复体验。索引不是越多越好多一个索引插入速度和存储成本都在上升解决一个真实慢查询再加一个索引才合理。6. 上线后的排错记录与同城场景优化实录6.1 门店距离列表偶发抖动的排查门店列表按距离排序上线后有用户反馈说“店铺排序不稳定有时候看着近的店被排到了后面”。排查原因是前端把定位经纬度缓存了 10 分钟用户在移动过程中位置没变但距离展示用的是缓存数据。后来改成每次进入列表页都重新获取定位但加了一个 30 秒防抖。对同城业务来说车主的位置是排序的最关键变量宁可多等一秒定位结果也不能用过期数据排序。高德 SDK 默认返回的定位精度描述里面误差在 40 米以上的场景直接放弃了距离排序的准确性代码里判断定位精度后才允许传参。6.2 集成环境状态推进失败导致的返工第二周门店店长反馈工单已经点“开始施工”了但车主端看到的状态还是“待施工”。日志一看是状态机校验时发现预期状态不符——同一订单有两处并发改了状态一处来自店长 PC 端“开始施工”请求一处来自定时任务“超时自动取消”。两个请求同时处理同一条订单后提交的请求因为前置状态已经从待施工变成已取消被状态机拦截掉报错提示“当前订单状态不允许此操作”。这个报错信息给店长看其实不直观后来把状态机校验失败提示改成“工单状态可能已被更新请刷新后重试”从产品上降低用户的焦虑同时在代码里保留告警每天盯一次日志看看有没有异常状态迁移。6.3 多门店授信与结算的快照方案服务类系统很容易在结算环节出纠纷。比如店长在施工中给车主加了一个增项车主确认后工单结算总额变化。如果平台按照确认当刻的金额算佣金之后改动价格就要重新走结算逻辑特别容易出对不上的账。我的做法是给结算模块单独做了一份快照。工单每一次金额变更都在结算快照表里记录变更前后的金额、操作人、操作原因。最终结算时读的是快照表里最新一条记录的金额同时这条记录还保留上一次金额。这样月底跟门店对账时每笔金额变化都有据可查不需要翻操作日志拼凑。7. 总结到项目自检这套源码能值多少把完整的源码梳理完我统计了一下整个系统核心代码大概 1.6 万行不算多但每个模块都在解决真实场景里的具体问题。作为练手项目它几乎覆盖了 Java 后端面试里高频涉及的核心点Spring Boot 自动装配、MyBatis-Plus 操作、Redis 缓存、分布式锁、状态机、策略模式、幂等设计、多角色权限。这些知识点在八股文里背一百遍不如在一套能跑起来的系统里亲手实现一遍。聊到 Java 基础这个项目也确实有它的价值。订单状态机的设计帮助你理解枚举在业务代码中的应用自定义注解加拦截器的思路考验你对反射和 AOP 的理解程度金额计算全程用BigDecimal不允许出现double这个约束本身就体现了一个 Java 开发者对精度的基本敏感。很多人背了 Java 面试题却写不出像样的项目问题往往就在缺少一套足够真实的业务载体。如果你准备拿这套系统作为学习模板我建议你别光看源码自己动手把状态机部分删掉重写一遍。手写一遍之后你会对状态流转的坑有更切身的理解比刷几十道面试题都管用。前面涉及的代码示例我特意留的都是核心片段完整工程里还有更多细节比如取消单自动退款、技师提成结算、门店评分模型这些后续可以再单独写文章展开。