货运搬家小程序源码开发从0到1（七）：司机端，抢单大厅与并发控制

订单进入待接单池子接下来是司机端的故事。这篇的并发问题值得单独一篇深度文见《一条 UPDATE 语句解决抢单并发》连载里讲整体设计。抢单大厅一个再普通不过的列表页大厅 查询所有status PENDING的订单按创建时间倒序、分页。司机端小程序轮询刷新第一版 30 秒一次够用WebSocket 推送是后期优化项。列表页有个体验细节展示距离而不是地址全称。订单表冗余存了起点经纬度司机端按自己位置算距离显示3.2km。详细地址抢单成功后才可见——既保护用户隐私也防止司机跳过平台私下接单。抢单整个项目最关键的一行 SQLLambdaUpdateWrapperOrderInfouwnewLambdaUpdateWrapper();uw.eq(OrderInfo::getId,orderId).eq(OrderInfo::getStatus,PENDING)// ★ 并发正确性全靠这个条件.set(OrderInfo::getStatus,ACCEPTED).set(OrderInfo::getDriverId,driverId);introwsorderMapper.update(null,uw);if(rows0)thrownewBizException(手慢了订单已被抢走);并发正确性由数据库行锁保证UPDATE 原子执行WHERE 匹配不到就影响 0 行。详细的方案推演为什么先查后改是错的、为什么这里不用 Redis我写在单独一篇深度文里此处不重复。抢单前的前置校验也别忘DriverdriverdriverService.mustApproved(AuthContext.uid());// 必须审核通过校验走普通查询落库走条件 UPDATE——校验可以宽松它不保证并发安全落库必须严格。接单之后司机驱动的状态流转司机端只有两个动作按钮都走同一个advance接口// action STARTACCEPTED → IN_PROGRESS// action FINISHIN_PROGRESS → COMPLETED 触发结算完成订单时顺带做钱包结算司机收入 总费用 × (1 - 平台抽成10%)加余额、记流水。结算细节下下篇展开。为什么不做指派模式大平台货拉拉有系统指派中小平台第一版只做抢单指派要解决司机画像、位置计算、拒单惩罚一整套问题抢单只需要一行 UPDATE。业务模式的选择和代码一样——先做对的再做多的。本篇成果司机端闭环抢单大厅 → 抢单 → 开始运输 → 完成结算。下一篇司机从哪来写司机入驻与资质审核流——这是平台合规的地基。