企业官网建设流程全解析

前阵子帮本地几家汽车改装店做了一套同城维修系统的订单管理后端，技术栈锁定 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；第二，这类业务系统后期一定会接支付、短信、地图、对象存储这些第三方 SDK，Java 的生态最全，遇到问题能查到的资料最多；第三，客户方通常希望后续能自己维护，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`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='预约订单表';

订单号生成我用的是日期 + 随机序列，没有用雪花算法，原因很简单——单库单表场景下雪花算法带来的复杂度大于收益。生成的订单号形如20250112103000123456，前面是年月日时分秒，后面六位随机数，再对订单号做唯一索引防重。

3. 核心源码实现：业务闭环的关键代码解析

3.1 基于JWT的多角色登录与权限控制

系统里有车主、店长、技师、运营四种角色，共用同一套用户体系。登录认证我选用 JWT 而不是传统 Session，原因是门店端技师可能同时在 PC 浏览器和手机小程序上登录，JWT 天然支持多端无状态认证，不需要额外维护 Session 同步。

JWT 令牌在登录成功后放进 Redis，key 为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 模块里定义了一个统一的返回包装类R<T>，包含 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 注入到Map<String, 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 面试题却写不出像样的项目，问题往往就在缺少一套足够真实的业务载体。

如果你准备拿这套系统作为学习模板，我建议你别光看源码，自己动手把状态机部分删掉重写一遍。手写一遍之后你会对状态流转的坑有更切身的理解，比刷几十道面试题都管用。前面涉及的代码示例我特意留的都是核心片段，完整工程里还有更多细节，比如取消单自动退款、技师提成结算、门店评分模型，这些后续可以再单独写文章展开。