一个做了三年日淘代购的团队，半年前决定自研一套代购系统。初衷很简单：市面上的SaaS要么太贵，要么功能不对口，不如自己搞一套。半年后，系统勉强能跑，但商品采集模块成了最大的坑——从淘宝和1688抓回来的商品数据，颜色尺码对不上、价格更新不及时、SKU映射全靠手工维护。运营每天花在“修正商品信息”上的时间比接单还多，有次因为价格同步延迟，一款爆款保温杯亏本卖了四十多单才发现进价已经涨了。

自研代购系统容易做成半成品，最难的部分往往不是订单和支付，而是商品采集这一环。

本文适合正在评估自研还是用成熟方案的开发者或代购团队负责人，前置知识要求对PHP后端开发和MySQL有基本了解。如果只做业务选型决策，可以跳过代码部分直接看架构思路和账本分析。

商品采集为什么容易做成半成品

代购的商品数据来源不止一个平台。淘宝的商品详情接口有反爬机制，批量抓取可能触发风控；1688的库存数据本身就有5到30分钟的延迟，大促期间更严重；不同平台的商品属性字段结构完全不同——淘宝的“颜色分类”在1688上叫“规格”，在品牌官网上可能叫“variant”。把这些异构数据清洗成统一的商品模型，工作量远超业务侧的CRUD。

一个典型的商品采集流程要经过三个环节：数据抓取、清洗映射、价格库存同步。多数自研项目在第一个环节就卡住了，不是因为抓不到数据，而是因为抓回来的数据无法自动化处理。下面拆开来讲每个环节的技术实现和常见坑点。

数据抓取：别在API上栽跟头

淘宝开放平台的API对商品详情接口有调用频率限制，基础版每天大概500次，企业高级版可提额。1688的企业认证账号日调用量大约5000次，QPS限制在每秒50次左右。自研系统如果不对API调用做频率控制和异常重试，上线第一周就可能因为触发限流被临时封禁。

一个可用的抓取层需要做两件事：调用频率控制和响应缓存。频率控制用Redis令牌桶，保证每秒请求数不超限。响应缓存则是因为代购商品的详情数据不需要每次都拉取——价格和库存可能每分钟都在变，但商品标题、规格、主图这些基础信息一天变不了一次。把基础信息缓存起来，只轮询价格和库存字段，API调用量能压到原来的三分之一甚至更低。

// 商品采集：基础信息缓存 + 价格库存实时拉取

public function fetchProduct(string $platform, string $productId): array

{



$cacheKey = "product:base:{$platform}:{$productId}";



$base = Redis::hgetall($cacheKey);



if (!$base) {



$base = PlatformAPI::getProductDetail($platform, $productId);



Redis::hmset($cacheKey, $base);



Redis::expire($cacheKey, 86400); // 基础信息缓存24小时



}



$realtime = PlatformAPI::getProductPriceAndStock($platform, $productId);



return array_merge($base, $realtime);

}

这个思路在Taocarts的商品同步模块中已有实践——商品基础信息缓存一天，价格和库存字段根据平台不同设置不同的刷新间隔，1688的库存刷新间隔比淘宝更短，因为1688的库存延迟本身就更大。

清洗映射：SKU对齐是体力活

多个平台的商品数据抓回来后，最大的工作量是SKU映射。同一件商品在淘宝上的SKU编码、1688上的规格ID、品牌官网上的variant_id，完全是三套命名体系。如果不做映射，客户在代购网站上下单“黑色L码”，系统不知道该发给淘宝的哪个SKU、1688的哪个规格。

自研系统在这个环节上最容易做成半成品——开始只想支持淘宝一个平台，SKU直接存淘宝的sku_id就行。后来加了1688，发现规格结构不一样，临时加了个platform_sku字段。再加品牌官网，字段彻底炸了，最后变成每个平台单独写一套解析逻辑，维护成本线性增长。

成熟的方案是在商品入库时就建立统一的内部SKU模型，外部平台的SKU作为映射关系存储。映射表的结构大致如下：

-- SKU映射表：将多平台规格统一到内部SKU

CREATE TABLE sku_mapping (

id INT PRIMARY KEY AUTO_INCREMENT,

internal_sku VARCHAR(64) NOT NULL,

platform VARCHAR(20) NOT NULL,

external_sku VARCHAR(128) NOT NULL,

external_name VARCHAR(255),

INDEX idx_internal (internal_sku),

UNIQUE KEY uk_platform_sku (platform, external_sku)

);

每次从新平台抓取商品时，系统自动检测该平台的规格列表，和已有内部SKU做名称相似度匹配。匹配不上的生成人工审核工单，运营在后台确认一次后写入映射表，后续该商品的所有规格自动对应。这个半自动化的流程比纯手工维护省了至少七成的时间。

价格同步与报价过期处理

代购系统的报价通常是在商品采购价基础上加一定比例的代购服务费。自研系统容易忽略的一个问题是报价过期——1688供应商调价了，代购网站上的报价还是旧的。客户按旧价格下单，采购时发现进价涨了，要么亏本采购，要么让客户补差价，两种结果都在消耗客户信任。

处理方案是在每次客户查看商品详情时检查报价的有效期，超过预设时间——比如15分钟——自动触发一次价格刷新。刷新期间如果接口超时，使用上一次的有效报价并在前端标注“报价更新中”。同时设置利润保护阈值：当采购价涨幅超过一定比例时，自动挂起该商品的自动采购，生成人工审核工单。

// 报价过期检测与利润保护

$quote = ProductQuote::get($productId);

if (time() - $quote->updated_at > 900) { // 15分钟过期



$latestPrice = PlatformAPI::getProductPrice($quote->platform, $quote->productId);



if ($latestPrice) {



$priceChange = ($latestPrice - $quote->cost_price) / $quote->cost_price;



if ($priceChange > 0.05) { // 涨幅超过5%触发审核



ProductMonitor::flagForReview($productId, 'price_surge', $priceChange);



}



$quote->updateCostPrice($latestPrice);



}

}

自研的隐性成本：算一笔账

很多人说“平台不好做”，但同样的平台，有人月流水破百万。差距往往不在选品眼光，而在系统能不能把商品数据的准确性兜住。自研一套代购系统，商品采集模块只是冰山一角。除了抓取和映射，还有多平台API限流适配、签名算法跟进、大促期间降级策略——这些不是一次性开发工作，而是持续的维护投入。一个两人开发团队，从零搭建到能稳定运行，两到三个月是正常周期，这还只是后端核心逻辑，前端、运维、安全合规都要另算。

成熟的代购系统在商品采集环节已经把淘宝、1688、唯品会等主流平台的接口适配封装好了，API签名升级由系统方统一更新，代购团队感知不到接口变动。对比自研方案，选择成熟系统相当于把持续的适配维护成本外包给了系统方，团队可以专注在获客和选品上。

干了六年的老代购说：“早几年觉得系统是噱头，白白多熬了那么多夜。”商品采集这件事，技术门槛不在能不能做，而在能不能持续稳定地做。接口会变、规则会改、平台会升级——自研系统如果没准备好应对这些外部变化，商品采集模块就会从核心竞争力变成持续漏水的短板。