Spring Boot物流平台搭建指南：从业务建模到线上性能优化

几乎每个Java开发者都写过物流管理系统——学校课程设计是它毕业设计是它简历上的项目经验还是它。但说实话市面上大部分“物流管理系统”都是披着物流外衣的单表增删改查一个订单表、一个司机表、一个车辆表撑死了加个分页查询跟真实的物流业务差了十万八千里。我去年接手了一个实际运营的物流平台重构任务从业务梳理到技术方案再到上线踩坑完整走了一遍。这篇就把整个过程拆开揉碎讲清楚物流平台到底要管什么数据、Spring Boot技术栈怎么选、核心表结构怎么设计、调度和计费这种关键流程怎么落地、以及上线后那些防不胜防的性能和可靠性问题。这篇文章面向两类人一类是准备用Spring Boot做物流类项目的开发者另一类是已经在做但觉得系统设计不成体系、想对齐一下真实业务场景的朋友。我尽量少说废话多给能直接拿走用的东西。1. 先捋清楚物流平台的业务边界订单、运单与结算很多项目做崩不是因为代码写得差而是因为压根没想清楚这个系统要装下多少业务。物流管理平台本质上是连接三方角色的枢纽货主发货方、承运方平台或车队、司机实际运输执行者。围绕这三方核心业务对象只有五个客户、订单、运单、车辆、司机外加一个贯穿始终的钱——结算。1.1 五个核心对象的职责划分订单Order业务入口。货主发起运输需求记录货品名称、数量、重量、体积、起运地、目的地、期望提货时间、运费约定等信息。订单是“业务事实”。运单Waybill执行单元。一个订单可能被拆成多票运单货太多一辆车拉不完一票运单也可以合并多个订单几个小订单凑一车走。运单绑定具体的车辆和司机是运输过程的跟踪载体。车辆Car运力资源。需要记录车牌号、车型、载重上限、容积、当前状态可用/在途/维修。司机Driver运输执行人。基本信息、驾驶证信息、当前任务状态。结算Settlement钱的归宿。按订单约定计费可能按重量、按体积、按车次、按里程生成应收账单和应付账单。这里第一个反常识的设计点不要把订单和运单合成一张表。我见过不少项目图省事一个order表里塞了承运信息、运输状态、签收信息结果业务稍微一扩张就彻底失控。订单是静态的业务描述运单是动态的执行轨迹两者的生命周期完全不同。订单可能挂几天没人接单运单一建立就要实时追踪。拆开之后后续的统计、对账、异常处理都有清晰的边界。1.2 为什么物流平台极度依赖状态流转物流的每个业务对象几乎都是状态机。订单有“待受理、已受理、已完成、已取消”运单有“待调度、待提货、在途、到达、已签收、已回单”。状态之间不是随便跳的从“在途”不能直接跳到“已签收”中间必须经过“到达”和“交接”。这些状态机是整个系统的中枢神经后面在数据建模部分我会详细展开。在动手写任何代码之前先把业务对象和它们的关系画清楚——这不是浪费时间的文档工作而是后面所有表结构、接口设计、权限划分的根基。2. 技术选型Spring Boot单体起步而不是直接上微服务现在一聊技术方案就有人提微服务、Spring Cloud Alibaba、K8s但物流管理平台这种系统本质上是一个高内聚业务、中等并发峰值每秒几百单已经算大平台了、强数据一致性的业务系统。我这次选型的原则就一条用最稳妥的组合满足业务需求不给运维添乱。2.1 最终技术栈组合与选择理由组件选型理由基础框架Spring Boot 3.xJDK 17生态成熟、自动配置丰富、上手快、招人容易ORMMyBatis-Plus物流业务大量涉及复杂多表联查、动态SQLMP的LambdaQueryWrapper能省很多样板代码数据库MySQL 8.x业务数据结构化程度高事务强一致MySQL完全够用缓存Redis热点数据车辆位置缓存、统计数据缓存、token消息队列RabbitMQ业务削峰轨迹上报、短信通知比Kafka轻量运维简单定时任务XXL-JOB分布式调度、日志可视化、失败重试方便接口文档Apifox/SpringDoc对内对外对接都靠它强调一下为什么不用JPA/Hibernate物流业务里查询非常动态——按时间范围、按状态组合、按区域、按货主各种字段排列组合JPA的Specification写起来极其痛苦而MyBatis-Plus的QueryWrapper加自定义XML组合几乎是碾压级的顺手。还有一点MP的代码生成器能在建模阶段快速铺底CRUD代码我后面会讲怎么用。2.2 单体加模块化比微服务更适合这类项目我见过一个失败的微服务案例把订单、运单、车辆、计费各拆一个服务结果运单流转一个操作要跨四个服务调用两个MQ消息排查一个问题要翻三套日志。物流平台的业务域之间耦合度极高——创建运单要查订单、要分配车辆、要冻结司机状态、要生成轨迹表这本质上是同一个事务或者最多两个事务的事。拆成微服务后分布式事务的复杂度最终一致性、对账补偿会把开发成本抬高一个量级。但完全的单体会在后期维护上吃亏。我的做法是Maven多模块的单体应用platform-common公共工具、统一返回体、异常定义platform-system用户、权限、组织架构platform-order订单管理platform-waybill运单管理、调度、轨迹platform-settlement计费、账单、对账platform-report统计报表模块之间通过Java接口调用禁止跨模块直接操作对方Mapper。这样既保住了单体的开发调试效率一个应用启动IDE里就能全部调试又留了后期按模块拆微服务的退路。2.3 开发阶段的工程化配置application.yml里我建议把环境配置抽成三套application-dev.yml、application-prod.yml共用一份application-common.ymlRedis、MQ、线程池等。物流平台要对接的外部系统很多——短信服务、地图服务、第三方轨迹查询、司机端App接口这些环境的地址、密钥、回调地址差异极大配置不分离联调的时候会乱成一锅粥。另外接口统一返回结构要设计好。我用的数据结构是{ code: 0, // 0成功非0失败 message: ok, // 错误信息 data: {} // 业务数据 }规格统一了前端调用、司机端对接、对外API全走这一套省得每个接口返回格式各写各的。3. 数据模型设计运单状态机是整个平台的中枢神经数据建模这块我直接把我最终落地的核心表结构拆给你看。大原则核心业务表尽量按领域建模冗余一些查询字段没关系但要控制更新的一致性。3.1 核心表结构梳理订单表 t_order字段类型说明idbigint主键雪花算法order_novarchar(32)业务单号格式前缀日期序列customer_idbigint货主IDcargo_namevarchar(100)货品名称cargo_weightdecimal(10,2)重量吨cargo_volumedecimal(10,2)体积方from_city / to_cityvarchar(50)起运城市 / 目的城市from_address / to_addressvarchar(200)详细地址expect_pickup_timedatetime期望提货时间freight_typetinyint计费方式1按重量 2按体积 3按车次freight_feedecimal(10,2)约定运费statustinyint状态0待受理 1已受理 2已调度 3已完成 4已取消create_time / update_timedatetime审计字段运单表 t_waybill字段类型说明idbigint主键waybill_novarchar(32)运单号order_idsvarchar(500)关联订单ID集合用逗号分隔冗余存储car_idbigint车辆IDdriver_idbigint司机IDstatustinyint状态机0待调度 1待提货 2在途 3到达 4已签收 5已取消pickup_timedatetime实际提货时间delivery_timedatetime实际到达时间sign_timedatetime签收时间sign_photo_urlvarchar(500)签收照片PODremarkvarchar(255)备注versionint乐观锁版本号轨迹表 t_waybill_track一条运单对应N条轨迹点记录经度、纬度、速度、方向、上报时间、上报设备。这个表是典型的高写入表下面会专门讲它的写入优化。3.2 运单状态机的严格流转设计我在代码里用一个枚举类定义状态机并在每个状态变更的方法里做前置校验public enum WaybillStatusEnum { PENDING_DISPATCH(0, 待调度), PENDING_PICKUP(1, 待提货), IN_TRANSIT(2, 在途), ARRIVED(3, 到达), SIGNED(4, 已签收), CANCELLED(5, 已取消); private static final MapInteger, ListInteger ALLOWED_TRANSITIONS new HashMap(); static { ALLOWED_TRANSITIONS.put(0, List.of(1, 5)); // 待调度 - 待提货 / 取消 ALLOWED_TRANSITIONS.put(1, List.of(2, 5)); // 待提货 - 在途 / 取消 ALLOWED_TRANSITIONS.put(2, List.of(3)); // 在途 - 到达 ALLOWED_TRANSITIONS.put(3, List.of(4, 2)); // 到达 - 签收 / 退回在途司机送错再修正 ALLOWED_TRANSITIONS.put(4, List.of()); // 签收后不允许变更 ALLOWED_TRANSITIONS.put(5, List.of()); // 取消后不允许变更 } public static boolean canTransition(int from, int to) { return ALLOWED_TRANSITIONS.getOrDefault(from, List.of()).contains(to); } }状态流转的逻辑为什么要单独抽出来因为物流场景下“司机误操作”是很常见的——司机点了“到达”才发现送错了地方需要撤回在途。这种业务诉求下状态流转必须做成可控的、可审计的而不是随手一个update ... set status 新状态。3.3 车辆与司机表设计的关键点车辆表要存载重、容积、车辆类型厢式/平板/冷藏这直接决定调度算法里能不能匹配订单。冷藏货匹配普通车厢货损了就是重大事故。司机表要存手机号、身份证号要脱敏显示、驾驶证到期日到期日前30天系统要自动提醒运营人员。这个模块常见的坑是司机手机号直接当登录账号。后面权限部分我会讲为什么必须拆一套独立的账号体系。3.4 经纬度存储与距离计算的选型轨迹点表的经纬度我建议存decimal(10,6)不要用浮点类型。浮点类型在存储和比较时会引入精度误差坐标差一点点距离算出来就差几十米。里程计算不用自己造轮子如果接的是高德或百度地图服务直接用它们提供的距离计算API如果只是想粗算比如按直线距离估算费用MySQL 8.0内置了ST_Distance_Sphere函数SELECT ST_Distance_Sphere( POINT(from_lng, from_lat), POINT(to_lng, to_lat) ) AS distance_meters;返回的是球面距离米对物流运输这种“公路会比直线远30%”的场景用来做费用预估或者运距对比够了。真要精确计费要用地图服务的驾车路径规划接口。核心原则计费口径提前定死不然财务那边天天跟你扯皮。4. 核心流程落地从下单到签收的关键代码实现数据模型定好后真正见功夫的是业务流程怎么串起来。我挑三个核心环节讲透订单受理生成运单调度、轨迹上报的批量处理、签收与计费的闭环。这三个环节覆盖了物流平台的高频操作和最容易出问题的数据一致性场景。4.1 调度订单如何变成运单并完成车辆分配调度的入口是运营人员把“已受理”的订单指派给某个司机和车辆。这里不能简单的insert一条运单就完事因为涉及多个表的一致性变更Transactional(rollbackFor Exception.class) public Waybill dispatchOrder(DispatchRequest request) { Order order orderMapper.selectByIdForUpdate(request.getOrderId()); if (order null || order.getStatus() ! OrderStatusEnum.ACCEPTED.getCode()) { throw new BizException(订单不存在或当前状态不可调度); } Car car carMapper.selectByIdForUpdate(request.getCarId()); if (car.getStatus() ! CarStatusEnum.AVAILABLE.getCode()) { throw new BizException(车辆当前不可用); } // 校验载重匹配 if (car.getMaxWeight().compareTo(order.getCargoWeight()) 0) { throw new BizException(车辆载重不足无法调度); } Waybill waybill new Waybill(); waybill.setWaybillNo(generateWaybillNo()); waybill.setOrderIds(String.valueOf(order.getId())); waybill.setCarId(car.getId()); waybill.setDriverId(request.getDriverId()); waybill.setStatus(WaybillStatusEnum.PENDING_PICKUP.getCode()); waybillMapper.insert(waybill); // 更新车辆状态、订单状态 car.setStatus(CarStatusEnum.IN_USE.getCode()); carMapper.updateById(car); order.setStatus(OrderStatusEnum.DISPATCHED.getCode()); orderMapper.updateById(order); return waybill; }两个加锁的细节要解释一下。selectByIdForUpdate是悲观锁防止两个运营同时抢同一辆车——虽然概率低但一旦发生就是两个运单都绑定一辆车线下配送直接乱套。为什么不用乐观锁因为调度是低频操作悲观锁的代价可以忽略而且它能在事务内把“查询校验更新”串成一个安全的原子流程。调度完成后通常要通知司机接单。这里用MQ发一条消息给司机端推送服务短信和App push都从这里触发避免同步调用的超时拖垮主流程。4.2 轨迹上报高并发写入场景的批量处理优化轨迹上报是物流平台唯一的高并发写入场景。司机端App每10秒上报一次经纬度1000辆车同时在途每秒就有100条写入。这个量不大但写法不当一样会把数据库拖垮。常见的错误写法是前端每收到一条轨迹就逐条insert到数据库。正确做法是App端本地攒一批比如30秒的轨迹点一次性POST给后端后端收到后做批量插入。MyBatis-Plus的批量插入用IService.saveBatch就行底层是foreach拼接SQL。但有三个坑必须提前规避第一单批次插入量不要太大。我实测过一条轨迹SQL里超过2000行容易触达MySQL的max_allowed_packet限制批量插入会整个失败。所以我限制每批最多500条超了就拆包分批插入每批之间不要求强一致性轨迹丢一两个点影响不大。第二轨迹表的索引要控制。这张表查询场景就两个按运单查轨迹、按时间范围查轨迹。建一个(waybill_id, track_time)联合索引就够别多加索引写入性能会明显下滑。第三轨迹数据是典型的“先落库后补信息”场景。司机上报的原始轨迹根本不知道属于哪一票运单通常App会带上waybillNo但偶尔也会有报文缺失。我加了一步兜底处理器轨迹入库后做一次匹配清洗——根据车辆ID和当前时间反查该车正在执行的运单补齐waybill_id字段。这样即使司机端报文异常轨迹也不会成为孤儿数据。4.3 签收闭环签收操作如何触发运费结算签收是整个流程的钱的入口必须保证“签收一次只结算一次”。我的做法是签收接口里同时做两件事更新运单状态为“已签收” 创建结算单应收。这两件事放在一个事务里通过运单状态机的乐观锁防重Transactional(rollbackFor Exception.class) public void signWaybill(Long waybillId, String photoUrl) { // 乐观锁更新前校验当前状态 Waybill waybill waybillMapper.selectById(waybillId); if (!WaybillStatusEnum.canTransition(waybill.getStatus(), WaybillStatusEnum.ARRIVED.getCode())) { throw new BizException(运单当前状态不允许签收); } Waybill update new Waybill(); update.setId(waybillId); update.setStatus(WaybillStatusEnum.SIGNED.getCode()); update.setSignTime(new Date()); update.setSignPhotoUrl(photoUrl); update.setVersion(waybill.getVersion()); // 乐观锁条件 int rows waybillMapper.update(update, new LambdaQueryWrapperWaybill() .eq(Waybill::getId, waybillId) .eq(Waybill::getVersion, waybill.getVersion())); if (rows 0) { throw new BizException(运单状态已变更请刷新后重试); } // 创建应收结算单 settlementService.createReceivable(waybillId); }这里解释一下为什么签收用乐观锁而不是悲观锁签收操作通过App端触发司机可能开着4G网络在偏远地区网络抖动导致重复提交。乐观锁天然支持“谁先成功谁生效”后到的请求因为version不匹配直接失败不需要等待数据库行锁用户体验更好前端拿到错误提示可以自动刷新状态。4.4 计费模块策略模式应对多变的计费规则计费是物流平台最容易变的需求——今天按重量明天按体积后天搞会员折扣。我的解法是把计费抽成策略接口public interface FreightCalculator { String getType(); // 计费类型 BigDecimal calculate(FreightContext context); } // 按重量计费 Component public class WeightFreightCalculator implements FreightCalculator { Override public BigDecimal calculate(FreightContext context) { return context.getUnitPrice().multiply(context.getWeight()); } } // 按体积计费 Component public class VolumeFreightCalculator implements FreightCalculator { Override public BigDecimal calculate(FreightContext context) { return context.getUnitPrice().multiply(context.getVolume()); } }用Spring注入所有实现类再通过一个Map做类型路由。以后要加按公里计费新增一个实现类就够了不改任何老代码。物流平台的计费规则通常还要支持阶梯价、最低消费、区域附加费策略模式叠加组合模式基本能覆盖这是我反复调整后认为最稳妥的方案。5. 权限与多租户物流平台的账号体系与数据隔离B端系统的权限设计不复杂但物流平台有个特殊点——同一套系统里跑着三类完全不同的角色平台运营、货主企业的操作员、承运司机。它们能看到的数据边界完全不同而且司机端往往还是独立的App走移动端接口不能直接复用后台的登录态。5.1 RBAC模型与数据行级隔离我采用的是经典RBAC模型用户表、角色表、用户角色关联表、权限菜单/按钮表、角色权限关联表。权限点控制到按钮级别比如“订单导出”“运单调度”“账单审核”各是一个权限点。光有功能权限不够物流系统还必须做数据权限。货主A登录后只能看到自己的订单和运单不能看到货主B的。这个用纯粹的业务代码写where customer_id ?会漏且难维护。我用的方案是MyBatis-Plus的DataPermissionInterceptorBean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new DataPermissionInterceptor(new MultiDataPermissionHandler() { Override public Expression getSqlSegment(Expression where, String mappedStatementId) { // 根据当前登录用户的角色动态拼接数据权限 if (isPlatformAdmin()) { return where; // 平台管理员不过滤 } if (isCustomerUser()) { return new EqualsTo(customer_id, getCurrentCustomerId()); } // 司机只能看自己的运单 return new EqualsTo(driver_id, getCurrentDriverId()); } })); return interceptor; }这个拦截器做的是SQL级改写每次查询自动拼接数据权限条件。它的好处是不管业务代码里怎么查最终执行的SQL都带着隔离条件后续接报表、接统计模块也不担心漏加where条件导致越权。5.2 登录态设计Web端JWT Redis司机端独立Token后台管理系统我用的方案是登录成功返回JWTToken里只存userId和角色编码完整的用户信息存Redis过期时间30分钟每次请求滑动续期。为什么不用纯JWT无状态因为物流后台需要实时踢人和强制下线——运营人员离职了管理员要能立刻失效他的会话。纯JWT做不到Redis会话可以。司机端App不共用这套体系。司机的账号是独立的一张t_driver_account表绑定手机号、openId、司机表ID。司机端接口统一走一套单独的鉴权拦截器只校验司机身份不校验后台角色。两个体系的用户表不能混用因为后台用户和司机信息的字段诉求完全不同硬套一张表会造成大量冗余字段。5.3 司机手机号变更的经典坑我踩过这个坑值得专门说。早期设计直接把司机手机号当作司机登录账号结果半年后运营反馈某个司机离职了新司机用同一个手机号接了他的活手机号是公司配的结果新司机登录后看到的是前司机的历史运单和数据。这就是把“账号身份”和“联系方式”耦合在一个字段的后果。正确的模型是t_driver表里存司机基础信息手机号是业务联系方式t_driver_account表里存账号账号绑定手机号但允许解绑重绑历史运单数据始终挂在driver_id上而不是手机号上。换了登录账号历史数据归属不受影响。6. 性能与可靠性缓存、异步消息与对账机制物流平台的数据量增长很快一天几千单三年下来就是百万级订单、千万级轨迹。虽然是中等规模不优化一样会卡。这里面有三件事我认为是最值得投入精力的热点数据的缓存策略、轨迹上报的异步削峰、以及对账兜底机制。6.1 缓存策略高频查询与统计的Redis缓存物流后台的高频查询集中在首页驾驶舱、订单列表、车辆状态。首页的“今日订单量”“在途车辆数”是运营每天打开系统第一眼看的绝对不能每次实时count数据库。我用Redis缓存统计结果key设计成dashboard:today:orders过期时间60秒每有新订单产生就更新一次统计值。这样刷新页面时几乎无延迟数据库压力也小。订单详情的缓存用order:detail:{id}缓存时间2小时订单状态变更时主动删除缓存。这里提一个经验物流业务的缓存不要用复杂的双写一致性方案Canal 双删搞得很重因为订单状态变更频率很低一个订单生命周期最多变五六次状态先更新数据库、再删缓存是最务实可靠的做法。缓存重建时可能短暂压力大但订单详情查询QPS本来就低完全扛得住。只有首页统计这种高频读场景才需要预热缓存。6.2 RabbitMQ如何吞掉轨迹上报的峰值轨迹上报前面说了采用批量上报但即便批量峰值也可能突然打上来比如某车队集体上线。我在上报接口和数据库之间加了一层RabbitMQ队列App上报轨迹 → HTTP接口只做参数校验 → 发送MQ消息内容是轨迹点列表→ 立即返回消费者从队列拉取 → 批量写入数据库这套异步削峰的收益是上报接口的RT从150ms降到20ms司机端App的体验大幅提升MQ队列做缓冲数据库不会因为瞬间的流量尖峰打满连接。消费者侧我做了手动ACK 批量消费prefetch300一次拉取300条轨迹点做一次批量插入吞吐量非常稳定。6.3 定时任务体系异常运单扫描与结算对账物流系统有一堆场景必须靠定时任务兜底。我这里挂了三个XXL-JOB异常运单扫描每30分钟扫描所有“在途”且最近120分钟没有轨迹更新的运单标记为异常通知运营介入。运费结算对账每天凌晨2点把当天所有已签收运单的应收账单和订单里的约定运费比对不一致的进异常池。合同到期提醒每天上午9点扫描客户合同、司机驾驶证、车辆年检的到期情况生成提醒清单。这里重点说对账任务因为它能兜住很多代码bug。比如司机把运单签收了两次重复请求乐观锁挡住了但万一某种边界场景下事务拆分导致结算漏单对账任务就能发现“有签收运单但无账单”的记录人工介入修复。没有对账机制的业务系统等于是在裸奔。6.4 第三方接口回调的幂等设计物流平台至少要对接两个外部回调地图服务的轨迹纠偏回调、司机端App的POD图片上传回调用OSS直传的话是OSS回调。回调接口最大的特点就是可能被重试——网络抖动一次对方就重发。我处理回调幂等的方案// 回调处理逻辑 try { // 1. 先查本地流水表是否有该三方回调ID的记录 CallbackRecord record callbackRecordMapper.selectByOutBizNo(outBizNo); if (record ! null) { return 已经处理过直接返回成功; } // 2. 插入一条处理中的记录靠 out_biz_no 唯一索引兜底 CallbackRecord insert new CallbackRecord(); insert.setOutBizNo(outBizNo); insert.setStatus(0); callbackRecordMapper.insert(insert); // 3. 执行真正的业务处理 handleCallback(insert.getId()); // 4. 更新状态为已处理 } catch (DuplicateKeyException e) { // 并发重复回调进来了直接忽略 return already processed; }核心是第三方回调ID做唯一索引利用数据库的唯一约束在并发场景下天然防重。这套方案代码量小、可靠性高够我处理所有回调场景。7. 上线后踩过的坑轨迹丢点、状态回退与消息重复的排查复盘这部分我挑几个最典型的线上问题讲排查思路比讲答案更有价值。7.1 轨迹出现大面积丢点问题出在批量插入的“假成功”现象有段时间司机反馈App上轨迹回放断断续续查看数据库发现部分运单的轨迹点确实少了。排查过程从三个方向展开App上报日志后端API的接收记录数据库insert结果最后定位在批量插入的saveBatch上——因为单据上报的某些批包含非法字段经度为null、速度值为负数MyBatis-Plus默认的批量插入遇到脏数据会整批失败而我当时的代码把失败直接吞了只打了一条WARN日志。修复方案分两层入参校验严格化App端和API层都对经纬度做范围校验数据库写入改为分批逐条容错——500条一批如果整批失败退化成每条单独校验单独插入最大程度保留有效轨迹点。轨迹数据本身允许小比例丢失但不能因为一个脏点丢掉整批。7.2 运单状态被并发回退乐观锁救了一半现象有运单明明司机已经点了“到达”运营后台却显示“待提货”。查代码发现运营在后台手动修改运单备注时updateById把整个运单对象的所有字段都更新了一遍而状态字段被旧数据覆盖回去了。这不是并发问题是部分更新接口把全量字段都带上了导致老数据覆盖新数据。修复方案所有修改类接口禁止直接传整个实体对象更新改为确定性更新只更新允许更新的字段Waybill update new Waybill(); update.setId(waybillId); update.setRemark(newRemark); waybillMapper.updateById(update);同时保留了乐观锁机制防止真正意义上的并发覆盖。这类问题的本质是MyBatis-Plus的updateById是全字段更新Null字段默认不更新但非Null一律覆盖粗心就会踩雷。7.3 MQ消息重复消费导致运费重复计算设备端上报轨迹的消息消费者收到一条重试了三次结果轨迹表里插了三条相同坐标的记录。这本身问题不大但后来结算消息也遇到重复消费差点给司机多算了一趟运费。排查链路梳理如下MQ消费端使用的RabbitListener默认是自动ACK业务处理异常后消息会重回队列如果出现网络闪断导致ACK丢失消息就可能被再次投递。我在消费者入口也加了幂等处理消费之前先查业务流水表处理过直接ACK丢弃。我现在对MQ消费的一个铁律是凡是会影响钱的消费一律走“本地业务唯一ID 唯一索引”防重不能只依赖MQ的at-least-once保证。7.4 一张错误索引让轨迹查询慢到打不开上线的第3个月轨迹表数据量到了300万运营反馈“轨迹回放”页面要卡5秒以上。看执行计划发现查询条件是waybill_id ? AND track_time ?但表上只有一个track_time单列索引由于索引区分度不够走了200万行的全索引扫描。修复就一句话加了一个联合索引(waybill_id, track_time)查询直接降到30ms以内。这类问题不值得惊讶但值得警惕——核心表的索引设计一定要模拟真实查询场景去推演而不是“哪个字段像主键就给哪个字段加索引”。最后分享一个排查线上的心得这套系统上线到现在我最大的体会是Spring Boot在技术上把很多复杂度兜住了但真正决定一个物流平台成败的是业务模型的稳定和数据的可靠。状态机设计得清晰后面加需求、扩流程都会顺状态机乱了每一处业务代码都埋着雷。另外一个很实在的经验是日志要舍得打但要有结构。我在轨迹上报、调度、签收、结算这四个核心环节都加了MDCMapped Diagnostic Context链路ID请求进来时生成一个traceId贯穿整个调用链。线上排查问题时拿着司机上报的一条轨迹的traceId能把从App入口到数据库写入的每一跳都串起来。没有这个排一次线上问题至少多花三倍时间。后续如果再演进我会往运力调度算法车辆与订单的智能匹配和司机端App离线补传这两个方向扩展前者提升运营效率后者提升轨迹完整率。这两块都建立在现有数据模型之上核心的表结构基本不用大改——这也是为什么前期把领域模型想清楚比急着堆代码重要得多。