企业官网建设流程全解析

从年初到现在，我一直在折腾一套面向汽车养护同城服务的 Java 后端源码项目。起因很简单：我认识的一位养护店老板，手里有 4 家直营店，每天订单全靠电话和微信，技师干完一单之后有无空档完全靠喊，车主在高峰期排队两小时没人通知。他说了一句话让我印象特别深——“平台上的订单是不少，可平台抽佣高、客户数据也不是我的，活动一停立刻没单”。这句话基本上就是汽车养护行业做同城数字化服务升级的核心逻辑起点。

这篇文章，就是把我这套 Java 源码从零搭建到最后落地运营踩坑的全过程做一次系统拆解。适合三类人看：一是想从传统门店向同城线上化转型的经营者，二是刚接触本地生活类业务系统、想找一个完整业务闭环练手的 Java 开发者，三是对订单履约、LBS、派单调度这类经典场景感兴趣的技术读者。我会把技术选型、源码级别的核心链路、以及实际部署运营中踩过的坑都摊开来讲，尽量做到能直接复现。

1. 传统汽车养护门店的订单断点：为什么需要自建同城服务

汽车养护和外卖、网约车最大的不同在于：它不是一个"30分钟必须送达"的即时服务，而是一个预约属性很强、履约过程很长、复购周期稳定的本地生活服务。洗车可能 30 分钟，基础保养 40 分钟，深度养护、贴膜、钣喷往往要半天甚至一整天才跑完。这个特性决定了系统设计不能照搬外卖那套高并发瞬时订单模型，而是要把重心放在预约、调度、跟踪、结算这四条业务主线的闭环上。

1.1 三方平台的双刃剑：有订单但没沉淀

绝大多数养护门店现在的订单来源无非两种：线下自然到店，以及美团、途虎、京东养车这类三方平台导流。线下到店不稳定，受天气、季节、节假日影响极大；三方平台倒是能稳定给单，问题在于每单抽佣 5%-10% 不说，车主的下单习惯、消费频次、车辆档案全部沉淀在平台上，门店充其量只是履约方。最难受的是，一旦门店想搞自己的会员营销、保养提醒、老客户回访，平台给不了任何数据支撑，甚至不允许跳出平台私下联系。

这也是同城服务自建系统的第一个出发点：把流量和数据的控制权拿回来。门店需要的不是要重新发明一个美团，而是搭建一套从"线上展示 - 预约下单 - 就近派单 - 技师上门/到店 - 完工结算 - 评价复购"的完整养修履约链路，将每一次服务产生的车型、里程、保养项目、技师手工会员卡数据形成资产沉淀。这正是 Java 后端 + 微信小程序/H5 端可以低成本实现的目标。

1.2 养护行业的时间和空间特征决定了系统重心

先看一组很典型的业务数据特征。以一个中等城市的汽车养护市场为例，订单高峰集中在周末上午 9 点到 12 点，以及工作日晚间 6 点到 9 点；周一至周四白天大量技师处于空闲状态；洗车和基础保养的到店预约提前期通常只有 1-3 小时，而深度养护、贴膜这类项目车主会提前 2-5 天预约。

这些特性推到系统设计上会形成一个判断：同城汽车养护系统的技术重心不在高并发流量入口，而在订单全生命周期的状态管理、门店与技师的调度算法、以及基于车辆档案的数据运营能力。而 Java 生态里 Spring Boot + MyBatis-Plus + Redis + RabbitMQ 这套组合，恰好是这个领域最成熟的基座。它不像自研一套实时撮合引擎那么重，也比 PHP 或纯前端方案更容易撑起后续多门店、财务结算、员工绩效这类复杂业务模型。

2. 系统技术选型与整体架构：Java 生态下的一套可落地组合

很多朋友一听到"同城服务"就觉得必须上微服务、必须搞 Docker/K8s、必须上 Spring Cloud Alibaba 全家桶。我的真实建议是：在日订单量没有超过 3000 单之前，单体应用 + 模块化分包就是最优解。微服务拆分解决的是团队协作效率和独立扩容问题，不是业务跑不跑得动的问题。早期养护平台的瓶颈根本不在接口吞吐，而在于业务规则复杂度和数据一致性问题，这些恰恰是单体架构更容易把持住的。

2.1 Spring Boot 3.x 模块化单体：先别急着拆微服务

我基于 JDK 17 + Spring Boot 3.1.x 搭建了这套源码，按业务域划分 Maven Module，而不是按技术层划分。这个设计思路在后期扩展时帮了大忙。

parent-bom （统一依赖版本管理） ├── quanshe-server # 启动主类、公共配置 ├── quanshe-api # 对外接口、DTO/VO 定义 ├── quanshe-core # 核心工具、公共异常、枚举 ├── quanshe-store # 门店管理：门店、工位、设备、营业时间 ├── quanshe-order # 订单域：预约、状态机、核销 ├── quanshe-worker # 技师域：技师、考勤、调度、任务 ├── quanshe-member # 用户域：JWT 认证、车辆档案、会员卡 ├── quanshe-marketing # 营销域：优惠券、活动、邀请有礼 ├── quanshe-finance # 结算域：价格、佣金、分账、对账报表 └── quanshe-common # Redis/MQ/短信/OSS 等基础设施封装

这样分包的好处是：代码结构上已经具备微服务的边界感，但部署时还是一个 Jar 包，不需要处理分布式事务和 RPC 调试成本。等门店数超过 50 家、需要按区域做独立的调度和容灾时，再根据订单域和技师域去拆微服务就行了。下面这张表是我实测过比较稳妥的技术选型：

2.2 核心业务模块的边界与服务关系

我画服务关系图时比较克制，把系统收敛成了五个关键域，这五个域基本能覆盖同城汽车养护 90% 的日常业务：

门店域是基础数据源，负责维护门店位置、营业时间、服务项目、工位数、服务范围半径。用户域负责 C 端车主身份体系的建立，包含一键登录、微信授权、车辆档案（车牌号、车型、里程、下次保养里程）。订单域承接车主下单动作，生成预约单后，根据门店距离和当前负载做推荐分配。技师域是履约核心，每个技师绑定到工位，通过任务永续查询的方式实时更新忙碌/空闲状态。结算域记录每一笔订单的收入、成本、优惠券分摊、技师提成，后续对账全靠它。

模块拆分最怕的就是把关系搞复杂，我的原则很朴素：所有跨域调用一律通过服务接口，禁止直接操作别的模块的表；所有状态变更必须走状态机，禁止 UPDATE ... SET status = 3 这种裸改。这个原则在后面派单、核销、退款流程中反复发挥了作用。

3. 源码级拆解：从车主下单到履约完成的核心链路

接下来这节是整个项目含金量最高的部分。我先按一条最主线的路径梳理：车主打开小程序 -> 选择附近门店 -> 选择服务项目 -> 预约下单 -> 平台派单给技师 -> 技师接单 -> 门店到店完成服务 -> 核销收款 -> 评价与复购。这里挑四个最值得抄作业的环节，单独展开源码。

3.1 门店推荐的 LBS 距离计算与服务覆盖圈

下单第一步，系统要根据车主的定位坐标，找出 3-5 公里内能承接服务的门店。最简单的做法是 API 请求里带经纬度，然后用 MySQL 的 ST_Distance_Sphere 函数直接 SQL 排序，但门店量起来之后这个方法非常伤数据库。我的做法是先粗筛、后精算：先用最大范围 5 公里换算经纬度差生成一个矩形边界，把候选门店过滤到十几家以内，再用 Haversine 公式精算真实球面距离，最后结合营业时间和预约负载排序返回。

public List<StoreDistanceDTO> findNearestAvailableStores(double lat, double lng, int limit) { // 1. 粗筛：以大约5公里为半径，换算经纬度边界，先在MySQL做矩形范围过滤 double latOffset = 5.0 / 110.574; double lngOffset = 5.0 / (111.320 * Math.cos(Math.toRadians(lat))); LambdaQueryWrapper<Store> wrapper = Wrappers.lambdaQuery(Store.class) .eq(Store::getStatus, StoreStatusEnum.OPEN) .between(Store::getLatitude, lat - latOffset, lat + latOffset) .between(Store::getLongitude, lng - lngOffset, lng + lngOffset); List<Store> candidates = storeMapper.selectList(wrapper); // 2. 精算距离，过滤出服务范围内的门店 List<StoreDistanceDTO> result = candidates.parallelStream() .map(store -> { double distance = GeoUtils.haversineDistance(lat, lng, store.getLatitude(), store.getLongitude()); return new StoreDistanceDTO(store.getId(), store.getName(), distance, store.getStoreLevel()); }) .filter(dto -> dto.getDistance() <= storeService.getServiceRadius(dto.getStoreId())) .sorted(Comparator.comparing(StoreDistanceDTO::getDistance)) .limit(limit) .collect(Collectors.toList()); // 3. 结合营业状态和当前预约饱和度，给门店加权排序 return businessService.applyLoadFactor(result); }

public static double haversineDistance(double lat1, double lng1, double lat2, double lng2) { double radLat1 = Math.toRadians(lat1); double radLat2 = Math.toRadians(lat2); double a = Math.sin((radLat1 - radLat2) / 2) * Math.sin((radLat1 - radLat2) / 2) + Math.cos(radLat1) * Math.cos(radLat2) * Math.sin((Math.toRadians(lng1) - Math.toRadians(lng2)) / 2) * Math.sin((Math.toRadians(lng1) - Math.toRadians(lng2)) / 2); return 2 * 6371.0088 * Math.asin(Math.sqrt(a)); }

这里有两个细节特别提醒：第一，门店的经纬度不要直接信任手动录入，最好接一次逆地理编码做自动校准，否则会出现门店明明在马路对面但算出来距离 5 公里的情况；第二，Haversine 公式假设地球是标准球形，对于同城 10 公里以内的短距离计算，误差控制在几十米级别，完全够用。

3.2 订单状态机：一次养护服务全流程的闭环控制

同城养护订单跟普通商品订单最大的差别在于状态多且会回跳。比如车主预约了周六下午 3 点的深度养护，但技师临时请假，订单就需要从"已分配"回退到"待分配"，同时要给用户发换店或改约通知。如果没有状态机约束，这些状态流转就会散落在一堆 Service 方法里，排查问题时会非常痛苦。

我用一个枚举类来维护所有合法流转：

public enum OrderStatusEnum { WAIT_PAY(0, "待支付"), WAIT_ALLOCATION(10, "待分配技师"), ALLOCATED(20, "已分配技师"), WORKER_ACCEPTED(25, "技师已接单"), IN_SERVICE(30, "服务中"), WAIT_MEMBER_CONFIRM(40, "待车主确认"), COMPLETED(50, "已完成"), COMMENTED(60, "已评价"), CANCELLED(90, "已取消"); private final int code; private final String desc; private static final Map<OrderStatusEnum, Set<OrderStatusEnum>> TRANSITIONS = new EnumMap<>(OrderStatusEnum.class); static { TRANSITIONS.put(WAIT_PAY, EnumSet.of(WAIT_ALLOCATION, CANCELLED)); TRANSITIONS.put(WAIT_ALLOCATION, EnumSet.of(ALLOCATED, CANCELLED)); TRANSITIONS.put(ALLOCATED, EnumSet.of(WORKER_ACCEPTED, WAIT_ALLOCATION, CANCELLED)); TRANSITIONS.put(WORKER_ACCEPTED, EnumSet.of(IN_SERVICE, WAIT_ALLOCATION)); TRANSITIONS.put(IN_SERVICE, EnumSet.of(WAIT_MEMBER_CONFIRM)); TRANSITIONS.put(WAIT_MEMBER_CONFIRM, EnumSet.of(COMPLETED)); TRANSITIONS.put(COMPLETED, EnumSet.of(COMMENTED)); } public boolean canTransferTo(OrderStatusEnum target) { Set<OrderStatusEnum> allowed = TRANSITIONS.get(this); return allowed != null && allowed.contains(target); } }

所有订单状态变更统一走OrderStatusTransitionService.changeStatus(orderId, sourceStatus, targetStatus)这个方法，内部会先查当前状态，再走canTransferTo校验，最后 UPDATE 时还会带上WHERE status = 源状态，避免并发场景下两个请求同时把订单拖到不同终态。这个设计后来在售后工单、退款流程里也直接复用，省了大量重复校验。

3.3 技师调度：忙闲状态的 Redis 缓存与分配策略

技师分配是同城养护系统里最有意思的部分。洗车这类短时高频服务适合抢单，技师有空就抢；但深度养护、贴膜这类长时服务必须走派单，要综合考虑技师技能标签、当前任务数、门店工位情况。我的方案是两种都支持，由商家后台按服务项目设定。

派单模式下，系统先查这个技师在目标时间段内是否有重叠任务，这个查询如果走 MySQL 会频繁产生慢 SQL。我的处理是给每个技师维护一个 Redis ZSet，score存任务开始时间戳，member存订单 ID，查询时用ZRANGEBYSCORE快速取出当天所有任务，再在内存里做时间段重叠判断。

public List<Worker> selectAvailableWorker(Long storeId, LocalDateTime planStart, LocalDateTime planEnd, Long skillTagId) { // 1. 获取门店下符合技能标签的技师 List<Worker> workers = workerMapper.selectList(Wrappers.lambdaQuery(Worker.class) .eq(Worker::getStoreId, storeId) .eq(Worker::getStatus, WorkerStatusEnum.ON_DUTY) .apply("FIND_IN_SET({0}, skill_tags)", skillTagId)); // 2. 利用Redis ZSet检查技师是否已有重叠任务 String key = RedisKeyBuilder.workerScheduleKey(storeId, LocalDate.now()); return workers.stream() .filter(worker -> { Set<String> orderIds = redisTemplate.opsForZSet() .rangeByScore(key, planStart.toEpochSecond(ZoneOffset.ofHours(8)) - 60, planEnd.toEpochSecond(ZoneOffset.ofHours(8)) + 60); return orderIds == null || orderIds.isEmpty(); }) .sorted(Comparator.comparingInt(worker -> worker.getCurrentTaskCount())) .limit(3) .collect(Collectors.toList()); }

这里有个很重要的细节：判断重叠时间段时，首尾各预留 60 秒缓冲。因为技师完成一个服务后需要收拾工位、录入回检单，如果前一个单子和后一个单子无缝衔接，现场很容易手忙脚乱。这 60 秒缓冲的成本几乎为零，但对技师体验的提升非常明显。

3.4 订单超时关闭与技师未接单自动重派

预约单支付后，系统会给技师推送待接单通知。但不是每次都能顺利接单，技师可能正在忙、手机没看、或者临时请假。如果不做自动处理，这个订单就卡死了。我的处理方式是引入 RabbitMQ 延迟消息：支付成功时发一条DelayMessage{orderId, expirationTime}，消费端收到后先检查订单状态，如果仍是"待分配"或"已分配"，就触发重新派单逻辑，同时给用户推送一条"技师调度中"的通知。

@RabbitListener(queues = "order.auto-repeat-dispatch.queue") public void handleRepeatDispatch(OrderTimeoutMessage message) { Order order = orderMapper.selectById(message.getOrderId()); // 只有仍然停留在待分配/已分配状态，才执行重派 if (order == null || (order.getStatus() != OrderStatusEnum.WAIT_ALLOCATION.getCode() && order.getStatus() != OrderStatusEnum.ALLOCATED.getCode())) { return; } dispatchService.dispatch(order.getId()); }

延迟消息的过期时间我最初设成 10 分钟，后来根据门店反馈调到 6 分钟。原因是主动点击"立即下单"的车主对时效预期很强，超过 5 分钟没响应用户流失率明显上升，6 分钟既能给技师留出反应窗口，又不会让用户等得失去耐心。

4. 同城服务的关键支撑：LBS 接入、消息触达与对账设计

订单链路跑通后，系统才到了一个勉强能用的状态。真正让这个项目从"演示 Demo"变成"能运营的系统"，靠的是另外三块基础能力：地图/LBS 的稳定接入、异步消息触达、以及财务结算对账。这三块表面上不如订单状态机那样有技术含量，但任何一个环节出问题，业务就会立刻崩盘。

4.1 地图能力接入：POI 检索、逆地理编码与服务范围圈定

同城服务的"同城"两个字，注定系统离不开地图相关能力。我这里选了高德开放平台，原因很简单：服务接入文档清晰、Web API 免费配额够用（企业认证后日调用量充足）、还有配套的小程序 SDK。实际开发中用到最多的能力是这三个：

• 逆地理编码：用户授权定位后，把经纬度转换为省份/城市/区县/街道文字，方便门店后台做区域统计；
• 距离计算接口（Web 服务）：骑行/驾车距离比直线距离更接近真实到店成本，我在推荐门店排序时会把驾车距离作为二级排序因子；
• POI 检索与周边推荐：门店管理后台可以按城市关键词检索并选定门店位置，省去手填经纬度的麻烦；
• 行政区域围栏 API：用于运营后台设定"服务开通城市"，把业务范围约束在已开通区域内。

接入地图能力时有一个坑必须提醒：高德用的 GCJ-02 坐标系与 GPS 原生坐标存在偏移，从小程序端wx.getLocation拿到的经纬度已经是 GCJ-02 加密坐标，所以直接传给高德 API 没有问题；但如果从 GPS 硬件设备（比如门店巡检设备）直接取点，就必须先做坐标转换，否则门店位置会整体偏移几百米。

4.2 服务范围如何圈定：圆形半径比行政区域更好用

最初设计门店服务范围时，我采用的是"门店所属区县"这种行政区域模式，原因很简单——运营人员看得懂。但实际跑了一个月后发现，行政区域和道路距离并不是一回事。一个门店如果恰好开在区县交界处，最核心的 3 公里范围内的用户可能被划到了隔壁区，于是系统推荐不到这家店，而实际上从这家店开车过去只要 5 分钟。

后来改为以门店为圆心、3-5 公里为半径的圆形服务圈，同时允许总部按门店级别调整半径（洗美店 3 公里、维修保养店 5 公里），这个方案准确率高得多。服务范围的真正含义不是"画个圈"，而是"在这个圈内我能稳定提供履约能力"。初期不要盲目扩大半径，宁可在覆盖范围内做深，确保每个订单都能在承诺时间内响应。

4.3 消息触达的方案：WebSocket + 短信网关的双通道

同城养护业务里，消息触达的实时性直接影响履约质量。车主下单后，希望尽快知道"谁在服务我、技师什么时候到岗/上门"；技师端则希望"新任务来了马上弹出来，不要靠 App 里手动刷新"。

技师端我用了 WebSocket 长连接 + RabbitMQ 广播方案。服务端有新的派单任务时，订单服务把 TaskAssignedEvent 发到 MQ，MQ 消费者再通过 WebSocket 推送给指定工号对应的长连接。推送给前端的消息体里只带任务 ID，前端收到后自己调详情接口拉取，避免把整个 DTO 序列化后塞进 WebSocket 消息导致带宽浪费。

C 端车主侧，考虑到微信小程序后台运行时长受限，我用的是订阅消息 + 短信兜底。关键节点（支付成功、技师已接单、服务完成待评价）发小程序订阅消息；如果 5 分钟内用户未查看，再发一条短信提醒。短信成本大约每条 4-5 分钱，对客单价几百元的养护服务来说是完全可以接受的运营成本。

4.4 财务结算：别等月底才对账，每单实时落账

汽车养护系统的财务复杂度被很多人低估了。一张 298 元的深度养护订单，可能构成是：车主付款 298 元，其中优惠券抵扣 30 元，平台补贴 20 元，门店实收 248 元，技师提成 80 元，平台服务费 40 元，剩余 128 元为门店收入。如果这些数字不按订单维度记录清楚，月底财务核算时会是一笔糊涂账。

我的解决办法是设计一张order_settlement_detail表，在订单完成时将整条链路的资金分摊一次性落库：

这样每天凌晨通过 XXL-JOB 跑一次对账任务：汇总当日完成订单的结算明细，与支付渠道账单核对总金额；不一致时告警并输出差异订单编号。这个机制帮我提前发现了好几类问题，比如优惠券重复核销导致的门店收入偏低、技师提成计算时没有排除平台补贴部分等，全部在月结之前就处理干净了。

5. 我复盘出的几个坑与优化建议

这部分原本想写成"避坑指南"，但实际写下来觉得更像是一次真实运营后的源代码级复盘。项目上线前我对自己的设计还挺有信心，直到真金白银的订单和真实用户的耐心涌入，才发现有些问题上线的瞬间就会暴露出来。

5.1 抢单模式的并发超卖：不是所有场景都适合 Redis 减库存

洗车这类短时高频服务，我给技师开放了抢单模式。最初实现是：技师点击抢单 ->redisTemplate.opsForValue().decrement("store:order:grab:token")-> 剩余量大于等于 0 就抢单成功。这个写法在低并发下没问题，但实测发现同一个任务被多位技师同时点击时，会出现两个技师都抢到同一单的情况。

根因在于decrement操作是原子的没错，但我后续的"抢单成功"写库动作并不是原子的，两个请求可以同时通过 decrement 判断，然后都执行了业务操作。正确做法是用Redis + Lua 脚本把"扣减 token + 检查剩余量 + 写技师与订单的关系"合并成原子操作：

local tokenKey = KEYS[1] local workerOrderKey = KEYS[2] local workerId = ARGV[1] local orderId = ARGV[2] -- 如果该技师已经抢过该订单，直接拒绝 if redis.call('SISMEMBER', workerOrderKey, workerId) == 1 then return 0 end local remaining = redis.call('GET', tokenKey) if tonumber(remaining) and tonumber(remaining) > 0 then redis.call('DECR', tokenKey) redis.call('SADD', workerOrderKey, workerId) return 1 end return 0

Lua 脚本在 Redis 中是原子执行的，从检查到扣减再到记录技师关系，不会被其他客户端插入中间状态。实际用下来，这个脚本在抢单峰值时延稳定在 3ms 左右，没有再出现过超卖。

5.2 技师位置追踪：别把 App 做成"电老虎"

系统上线第二周，门店反馈技师手机掉电极快，一天要充两次电。排查后发现原因非常简单：我为了做技师到店轨迹和实时位置展示，让技师端每隔 5 秒上报一次 GPS 坐标，HTTP 请求频率太高，屏幕常亮加上网络通信，直接吃掉了大量电量。

优化方案是双管齐下。前端根据场景动态调整上报频率：App 在前台且处于任务进行中时每 15 秒上报一次；切到后台但任务仍在进行时每 30 秒上报一次；后台且无任务时停止上报。服务端则不再把每一次坐标都写入 MySQL，而是先写到 Redis List 里，每 5 分钟批量落库一次。这样既保住了轨迹完整度，又把电量消耗控制在可接受范围。

5.3 营销补贴与技师提成：优惠券分摊最容易算错账

有一段时间财务反馈，部分订单门店实际收入比预期低。排查后发现是优惠券分摊逻辑写错了：某张 30 元优惠券本应由平台承担，但我写结算逻辑时把优惠券金额直接记成了门店让利，导致门店收入被克扣。这个问题的根子在于开发时没有明确"补贴资金归属"这个业务概念。

处理方式是在营销模块统一维护一个"优惠活动计费类型"字段：PLATFORM_SUBSIDY（平台补贴）还是STORE_GIVE（门店让利）。在订单生成结算明细时，根据这个字段决定优惠成本记到平台还是门店头上，而不是简单把订单优惠金额统一从门店收入里减掉。这种口径问题越早规范越好，后续接财务总账系统时才不用翻历史订单。

5.4 车辆档案是复购利器，但也需要运营支持

从源码角度看，车辆档案表的设计非常容易，但让它发挥价值需要运营策略配合。车主第一次完成服务后，系统根据车牌号、车型、本次保养项目，自动推算建议下一次保养时间（机油保养按 5000-8000 公里或半年，空调滤芯按 1 万公里或一年）。这个"保养到期提醒"功能在代码实现上不复杂，但真正把复购率从 17% 拉到 33% 的，是运营在提醒文案和优惠策略上的配合，而不是技术本身。

具体做法是：XXL-JOB 每天凌晨扫描即将到期的车辆档案，生成待提醒列表；优先给 30 天内到期且在 6 个月内有过到店记录的车主发送提醒短信和小程序订阅消息；文案不打“保养提醒”这种阳春白雪的话，而是加上门店最近可预约的空闲时段和一张小额优惠券。这套组合拳的转化效果远好于偶然性回访。

写在源码之外的一点体会

跑完整个项目，我最深的感觉是：汽车养护同城服务系统的技术难度，不在某个单一功能的算法复杂度上，而在于业务状态和资金状态的一致性保障。Java 生态里 Spring Boot、Redis、MQ 提供的都是通用能力，真正决定这个系统好坏的，是我有没有想清楚每一个状态什么时候变、怎么变、变了之后哪些数据需要同步调整。比如订单状态改成"已完成"的瞬间，技师提成有没有结算、优惠券有没有核销、车辆档案有没有更新下次保养日期，这四件事必须在一个事务里完成，少一件后期对账都会很难受。

如果让你在这个项目上做二次扩展，我建议优先做技师端 App 的离线缓存能力——洗车车间里网络信号往往不好，技师在车库和车间之间移动时，任务列表刷新失败率会偏高。这块做好之后，整个系统的稳定性会更上一层楼。