旅游 · 平台

自驾游平台的真实难点：库存、调度和结算

自驾游平台的复杂度不在页面，在后台。渤溢云拓 CTO 曹昕拆解线路库存并发、领队调度、供应商对账结算与在路上履约的异常处理。

很多人以为自驾游平台就是“把线路发到网上、让人下单”。

真做过的人都知道：下单只是开始，后面全是坑。

一个 3 天的自驾游产品，背后涉及车位数、房间库存、领队档期、供应商报价、退改规则、保险、结算周期。任何一环出错，用户在路上，客服在群里，技术在后端。

这篇讲我们在这套系统里踩过的四个真问题。

一、库存：不是减一，是“锁”

最朴素的实现是：下单时库存减一，取消时加回来。

这个方案在并发下单时会超卖，因为“查询—判断—扣减”不是原子的。更麻烦的是库存不是单一维度：一条线路可能包含 3 个房型、2 种车型、4 个出发日期，任意组合都可售。

我们的做法是分段锁库存：

1. 下单先创建占用记录（不直接扣库存），带过期时间；
2. 支付成功才转为正式扣减；
3. 占用超时未支付自动释放；
4. 取消按退改规则计算可释放数量。

关键在于“占用”和“扣减”分开。这样既解决了并发超卖，也让“待支付”状态有迹可循——出问题能查到是谁占的、什么时候释放的。

库存系统里最贵的 bug，不是少卖，是超卖。

二、调度：领队不是商品

线路的供给能力，最终落在“有没有合适的领队”。

这件事不能当成库存来算，因为领队有属性：

• 资质（是否持证、是否熟悉该线路）；
• 档期（连着几天不能接团）；
• 匹配度（带亲子团和带越野团不是一回事）。

我们把调度做成了两步匹配：

1. 硬约束过滤：档期冲突、资质不符直接排除；
2. 软评分排序：按历史评分、熟悉度、近期工作量打分。

然后保留人工干预。因为真实业务里总有例外——老领队临时有事、客户点名要某位领队。系统给出推荐，人做最终决定，而不是系统直接锁死。

能用算法解决的用算法，需要担责的留给人。

三、结算：先有对账，才有结算

旅行社会计最痛的不是算钱，是对不上账。

一个订单可能涉及：平台、组团社、地接社、车队、酒店、领队。每一方的结算口径不同、周期不同、发票要求不同。

我们的设计原则是：先建立统一的账目流水，再谈结算规则。

具体做法：

• 每一笔钱的变动都产生一条不可变的账目记录（记账，不是改余额）；
• 余额由流水计算得出，允许重算；
• 结算单是从流水里按规则聚合出来的快照，可对账、可复核、可导出。

这套设计多写了不少代码，但换来的是：任何一笔账都能追溯到“谁、什么时候、因为什么”。出争议时不用翻聊天记录。

四、异常：用户在路上的时候，系统不能只会报错

自驾游的特点是履约发生在路上。这时候故障的代价和后台不一样。

我们做了三件事：

1. 离线优先：领队端的关键信息（行程、联系人、集合点）本地缓存，没信号也能看；
2. 事件留痕：每一次变更（改期、换房、加人）都记录操作人、时间、原因；
3. 兜底路径：关键接口失败时，前端不是弹“网络错误”，而是给一个人工入口（打电话、发消息）。

第三点最容易被忽略。用户在路上遇到问题，最需要的不是重试按钮，是有人接。

五、一个反直觉的结论

做完这套系统，我最大的感受是：

旅游平台的竞争力，不在前端的行程展示，在后端的异常处理能力。

因为正常流程谁都能做，异常流程才是真实世界的日常。天气变了、车坏了、客人临时加人、酒店超售——这些才是每天发生的事。

系统设计时，先问“出错怎么办”，再问“正常怎么走”，顺序反过来，架构会完全不一样。