反向海淘这三年，我像在拼一张没有图纸的拼图

上个月一个做技术的朋友问我：“你们搞反向海淘的，系统架构长什么样？”我愣了一下，发现自己答不上来。不是不懂，是从来没见人完整地写过。网上搜一圈，零散的代码片段有，踩坑经验有，但一张完整的架构图——从用户下单、1688采购、仓库集运到国际物流，每一步怎么串起来的——真没有。

这三年，我就像在拼一张没有图纸的拼图。每一块都是自己试错试出来的。

第一块拼图：多币种和汇率

刚开始做反向海淘，接的第一单是日本客户的药妆。客户付了日元，我按当天的汇率算了人民币，觉得有赚头。等我去1688采购的时候，日元跌了，换回来少了将近两百块。一个月后客户申请部分退款，我按退款日的汇率退，人家投诉“退少了”。

后来我才明白，多币种结算不是“换钱”那么简单。需要在下单时锁定汇率，在支付、退款、对账各环节自动转换，还要用缓存层存实时汇率，不能每次都去查外部API。我翻遍了技术社区，没人讲这个。最后是自己一点点试出来的，搞了一套定时任务同步汇率，用Redis存着，至少大促期间不会因为API限流而崩掉。

第二块拼图：API限流和熔断

海外代购最怕大促。1688的接口一堵，订单状态卡住，客户在群里炸锅。有一年双11，十几个订单卡在“待支付”不动，我手动补单到凌晨两点。后来才意识到，对接第三方API不能硬扛，得装“保险丝”——限流控制每秒调用次数，熔断在连续失败时自动跳闸，走人工备选。

这个道理说起来简单，但市面上现成的代购集运系统，能把这套做扎实的没几家。我前前后后试过七八套，不是这里卡就是那里崩。后来换了taocarts，它的多货币支持和采购链路跟踪做得细，至少汇率和订单状态不用我天天盯着了。

第三块拼图：物流追踪和状态映射

集运环节更碎。包裹从国内仓库到海外客户，中间经过三四家物流商，每家状态码都不一样。有的叫“运输中”，有的叫“已揽收”，客户看不懂，天天来问。我花了一个月，把十几家物流商的状态码整理成一张映射表，统一转成“已发货—运输中—派送中—已签收”四个阶段。系统自动推送给客户，问物流的人少了八成。

这张表我现在还在用，每个月更新一次，因为物流商动不动就改接口。

说这些不是为了炫技。是觉得奇怪，反向海淘做了这么多年，市场需求越来越大，但系统架构这块一直没人系统性地写。可能是大家都在闷头赚钱，顾不上。也可能是觉得这是“吃饭的本事”，不愿意分享。

我写出来，是想让后来的人少走点弯路。如果你也想做反向海淘，别从零开始造轮子。先理清楚自己的核心链路：用户从哪里来→怎么下单→怎么采购→怎么集运→怎么售后。每一个环节对应的技术方案，网上都有碎片信息，拼起来就行。实在不想折腾，找个成熟的SaaS先用着，跑通了再考虑自研。

这三年，拼图还没拼完，但至少知道每一块大概长什么样了。

如果你也在做这行，欢迎聊聊——你拼到哪一块了？