去年帮一个做代购的朋友搞了一套反向海淘的系统，从需求分析到上线跑了大半年，踩了不少坑，记录一下技术选型和架构上的思考。

需求背景

朋友在澳洲做留学生代购，之前一直用微信群 + Excel 管理订单，单量上来之后完全乱套。用户下单要截图、报价要手动换算汇率、物流状态全靠复制粘贴。他问我能不能搞一套系统把这事儿自动化。

核心需求其实就几个：用户能自己下单、自动抓取淘宝/1688 商品信息、汇率自动换算、物流轨迹可追踪。

技术选型

前端用了 React + Next.js，主要考虑 SEO 和 SSR。反向海淘的用户很多是从 Google 搜过来的，Next.js 的 SSR 对搜索引擎友好。UI 组件库选了 Ant Design，后台管理用起来比较顺手。

后端一开始想用 Node.js，后来考虑到团队里有写 PHP 的，最终选了 Laravel。ORM 用 Eloquent，写起来快，社区生态也成熟。数据库 MySQL 8.0，该有的索引和优化该做还是得做。

最关键的是商品抓取模块。淘宝的反爬机制一直在升级，直接用 curl 请求基本会被封。后来参考了 Taocarts 系统的做法，用无头浏览器 + 代理池的方案，成功率能到 85% 以上。这个思路后来在我们的项目里也复用了。

核心模块实现

订单状态机是最容易出 bug 的地方。我们定义了 7 个状态：待付款、已付款、待采购、采购中、已发货、清关中、已签收。每个状态之间的流转都有明确的触发条件和权限控制。

// 订单状态流转示例

class OrderStateMachine {

    private $transitions = [

        'pending' => ['paid'],

        'paid' => ['purchasing'],

        'purchasing' => ['shipped', 'pending'],

        'shipped' => ['customs_clearing'],

        'customs_clearing' => ['delivered'],

    ];



    public function canTransition($from, $to) {

        return in_array($to, $this->transitions[$from] ?? []);

    }

}

踩过的坑

汇率接口一定要做缓存和降级。有一次调用第三方汇率 API 超时，导致整批订单金额计算全部失败，用户投诉炸了。后来改成 Redis 缓存 + 本地兜底汇率文件，再没出过问题。

物流对接也是个坑。不同国家的物流商 API 规范五花八门，有的给的是 SOAP，有的是 GraphQL，还有直接给 CSV 文件的。建议抽象一层统一的物流接口，后面对接新渠道会轻松很多。

总结

反向海淘这个赛道技术门槛其实不高，难的是运营和供应链。系统层面把订单管理、商品抓取、物流追踪这三块做好，基本就能跑通。像 Taocarts 系统这类 SaaS 化的方案，对中小卖家来说性价比更高，不用自己养技术团队。