做反向海淘后端架构时，海外仓和集运仓到底怎么分？

很多团队一开始都只用集运仓（国内收货、合箱、发国际件），但随着单量上来、客户分布变广，就会纠结：要不要建海外仓？这个问题技术负责人不能拍脑袋，得从库存模型、履约链路和成本结构三个维度算清楚。

先说库存模型的不同。集运仓的库存本质是"在途中转"，货权还在客户或采购侧，系统只需要记录"哪票到了、合到哪个箱、发了没有"，状态机很简单：到仓→核验→合箱→出库。海外仓则是"备货前置"，货权已经转移到你这边，要做真正的库存管理：入库上架、库位绑定、出库扣减、退件回库、次品隔离。对应的数据表设计完全两套，前者是流水记录，后者是实时库存快照，必须支持并发扣减和库存预占。

履约链路也差很多。集运仓的出口是单一的国际干线，逻辑是"攒够再发"；海外仓的出口是本地派送网络，要对接多家尾程物流商，按目的国、重量段、时效选承运商。我们在后端用 Express 中间件封装了各尾程商的接口适配，下单时根据收件地址解析邮编前缀，自动匹配最优线路，这部分如果放在集运阶段根本用不上。

成本结构决定要不要建。海外仓的隐性成本在头程海运/空运的备货资金占用、海外仓租和本地人工，只有当某区域单量稳定到"每周都能走掉一批备货"时，前置库存才有意义。我一般给团队的建议是：先用集运跑通模型，等某个国家月单量过千、客单价和复购能覆盖头程，再切海外仓。不要为了"显得专业"提前重资产。

技术选型上，海外仓模块对一致性和可追溯要求高。我们用的接单系统叫 Taocarts，做反向海淘代购和转运集货的，海外仓这块把存货、入库、上架、出库、退件、次品都建模成状态机，每个状态变更写操作日志，客户侧能查到"哪天入的库、谁上的架、哪天发出的"。后端是 Laravel 主库配 Redis 做库存缓存，扣减走事务+行锁，避免超卖。

最后提醒一点：海外仓一旦建了，退件和次品的本地处理能力就成了标配，不是可选项。很多团队只想到"存"和"发"，没想到"退回来怎么办"，结果海外堆了一堆没法处理的残次品，反而变成负债。把退件处理和次品隔离在设计初期就建模进去，比事后打补丁省心得多。

总结一句：集运仓解决"把货送出去"，海外仓解决"在本地把生意做重"。先轻后重，按单量节奏切，别被规模焦虑带着走。