跳到正文

物流

同城货运平台(乘客 / 司机 / 后台三端)

抢单调度、分布式锁防重复接单、订单状态机、取消退款规则留痕;多时区。

已上线物流大型项目iOS / Android App · PC
客户
Star X Tech(澳大利亚)
行业
物流
终端
iOS / Android App · PC
规模
大型项目 · 2026

01项目背景

Star X Tech 在澳大利亚做同城拉货、搬家和跑腿服务,用户是个人和小企业。传统做法靠电话派单、凭经验匹配车型,价格怎么算、订单走到哪一步都不透明,取消和退款纠纷只能线下沟通。需要乘客、司机、运营三端打通,让匹配、价格、状态和结算都有据可查。

客户类型
澳大利亚同城货运与搬家平台
用户角色
乘客、司机、运营人员
服务形态
拉货跑腿、搬家;预约单与即刻单
上线终端
iOS / Android App、PC 运营后台

02业务痛点

1电话调度漏单

靠电话派单、凭经验配车型,高峰时段容易漏单。

2价格不透明

里程费、搬运附加费怎么算用户看不到,结算时纠纷多。

3订单难以追踪

从下单到付尾款环节多,用户和运营都看不清进度。

4取消退款无留痕

取消扣多少、退多少靠线下沟通,没有统一规则和记录。

同城货运要快匹配、明价格、可追踪,电话和 Excel 管不住这条链。

03解决方案

乘客 App、司机 App、PC 运营后台三端分离,共用一套 Spring Boot 后端统一管理订单生命周期。并发交给 Redis 锁,状态流转交给状态机,取消退款按规则计算并落库留痕。

订单池抢单

乘客付首款后订单进入订单池,向符合条件的在线司机广播,服务端按先到先得确定接单人。

分布式锁防重复

按订单维度加 Redis 锁,持锁后再查一次订单状态,同一订单只会被一名司机接走。

订单状态机

从待支付、待接单、已接单到完成、取消、退款,合法跳转集中定义,非法操作直接拒绝。

取消规则分档

预约单按距服务时间、即刻单按距接单时间分档计费;司机出发后乘客不能自助取消。

退款分级处理

无手续费且已付款的订单自动原路退款;有扣费或渠道退款失败的转运营人工处理。

多时区统一

时间统一按 UTC 存储,按用户所在时区展示,夏令时按时区规则自动处理。

04核心流程

订单全流程

  1. 1

    下单估价

    选地址和车型,预估价格并用券

  2. 2

    支付首款

    付款后订单进入订单池

  3. 3

    司机抢单

    广播派单,服务端先到先得

  4. 4

    出发履约

    司机导航前往,乘客全程跟单

  5. 5

    送达确认

    司机上传送达证明

  6. 6

    支付尾款

    乘客结清尾款,订单完成

  7. 7

    评价申诉

    乘客评价服务,有争议可申诉

关键节点设超时自动取消,申诉期间订单状态冻结;司机接单 5 分钟内可无责取消,订单自动回到订单池。

05项目价值

并发不重复接单

锁管并发、状态机管规则,同一订单同一时刻只有一个写入者,非法跳转一律拒绝。

每笔取消可复盘

取消记录保存操作角色、原因、已付、应退、手续费和计算公式,客诉有据可查。

自动退款控风险

只有无扣费的订单自动退款,其余由运营确认后处理,避免退错款。

时区一次处理到位

存储用 UTC、出参按用户时区转换,新增接口无需各自处理时间。

06界面展示

后台取消与退款处理
司机端任务大厅抢单
乘客端订单跟踪

界面图为原型或用示例数据重做的界面,不含真实客户数据、金额与账号。

07技术栈

后端
Spring BootSpring StateMachineMyBatis-FlexJWT
数据与缓存
PostgreSQL(timestamptz)Redis / Redisson 分布式锁
移动端
跨平台框架,统一编译 iOS / AndroidGoogle Maps
运营后台
Vue模块化后台框架

有类似的业务问题?

先看看我们是怎么合作的:从需求梳理、原型到上线交付,每一步都提前讲清楚。