刚开始做代购那会儿，代购网站开发基本靠“人肉运维”。客户下单→手动去1688下单→Excel记库存→微信收款→手写快递单。日单量二三十的时候，这套流程勉强跑得动。直到有一天，一个客户下了50单，熬到凌晨三点还没对完账，第二天发现汇率从6.8涨到了6.9，那批货直接亏了将近两千块。
那是我第一次意识到：代购网站开发不是写个页面就完事，背后是一整套“人-钱-货-物流”的协同系统。今天聊聊踩过的坑，和后来怎么用系统把“一个人扛”变成“系统扛”。
第一个坑：库存数据同步，差点被“多卖”搞死
代购最怕什么？客户下单了，结果1688那边没货了。早期用Excel手动更新库存，每天更新一次。结果有一次双11，1688那边库存变化太快，下午更新的时候显示有货，晚上客户下了十几单，第二天一看全没货了。那几天光退款道歉就花了大半天。
后来学乖了，代购网站开发的核心之一是库存实时同步。接入了1688的官方API，商品库存每五分钟同步一次。但问题又来了：API调用有频率限制，而且1688那边库存变化是异步的，你查的时候有货，下单的时候可能已经没了。
解决方案是库存预占 + 异步确认：
- 客户下单时，系统先预占本地库存（从同步数据里扣）
- 然后异步去1688确认实际库存
- 如果实际没货，自动触发退款或换货流程
- 预占库存超过15分钟未确认，自动释放
这个逻辑看着简单，但坑在并发。双11高峰期，同一个商品被几十个人同时下单，预占和释放的顺序一乱，就会多卖。用Redis做分布式锁，每个商品ID一个锁，下单前先拿锁，拿不到就排队。这才把“多卖”的问题压下去。
# 伪代码：库存预占逻辑
def preoccupy_stock(product_id, quantity):
lock_key = f"stock_lock:{product_id}"
if redis.setnx(lock_key, "1", ex=10): # 10秒超时
local_stock = get_local_stock(product_id)
if local_stock >= quantity:
reduce_local_stock(product_id, quantity)
redis.delete(lock_key)
return True
redis.delete(lock_key)
return False
else:
return False # 拿不到锁，排队重试
第二个坑：汇率波动，一个月白干
代购的利润本来就不高，一单赚个十几块到几十块。但汇率一波动，利润可能瞬间变负数。有个同行，做日本代购的，日元一个月内从0.048涨到0.052，他所有订单都是按0.048报价的，那个月亏了将近三万。
代购网站开发必须内置汇率缓冲机制。后来在系统里做了这么几件事：
- 汇率加点：中间价基础上加1%-2%作为代购汇率，这个点覆盖汇率波动
- 汇率锁定：客户下单时锁定汇率，后续波动不影响已下单的订单
- 汇率告警：当实时汇率超过锁定汇率一定比例（比如3%），系统自动告警，人工决定是否调价
最核心的是汇率锁定。客户下单那一刻，系统把当时的代购汇率写入订单，后续不管汇率怎么变，这个订单的结算汇率不变。这样客户有确定性，我们也有确定性——亏赚都在下单那一刻决定了。
// 汇率锁定逻辑
function lockExchangeRate(order, baseRate) {
const markupRate = baseRate * 1.02; // 加2%作为代购汇率
order.lockedRate = markupRate;
order.lockedAt = new Date();
// 写入订单表，后续结算用这个汇率
db.orders.update(order.id, {
exchange_rate: markupRate,
rate_locked: true
});
}
第三个坑：对账，从Excel到系统自动对账
日单量几十的时候，Excel对账勉强能跑。但做到日单几百的时候，Excel根本扛不住。见过最夸张的一次：一个客户下了200多单，分三个批次发货，每个批次运费不同，还有部分退款。用Excel对了整整两天，最后发现差了两百多块，死活找不到原因。
后来做了自动对账系统，核心逻辑是：
- 订单维度对账：每个订单的收入（客户支付）和支出（采购成本+运费+平台用金）自动匹配
- 批次维度对账：同一批次的订单汇总，和物流公司的账单对
- 异常标记：对不上的订单自动标红，人工介入
这个系统上线后，对账时间从两天缩到了十几分钟。而且发现了很多之前Excel对不出来的问题：比如某个平台的用金算错了，某个物流公司的运费多收了。
代购网站开发的对账模块，是利润的“最后一道防线”。很多代购死就死在账对不清，利润被各种隐藏成本吃掉。
第四个坑：系统扛不住，双11崩了三次
有一年双11，系统崩了三次。第一次是数据库连接数满了，第二次是1688API回调超时，第三次是Redis内存爆了。
那次之后，做了几件事：
- 读写分离：读库和写库分开，读库挂了不影响下单
- 队列削峰：所有API调用走消息队列，不直接同步调用
- 熔断降级：当某个服务响应超过阈值，自动熔断，返回降级数据
最实用的是队列削峰。双11高峰期，1688的API响应很慢，如果同步调用，一个请求等几秒，几十个请求就把线程池打满了。改成异步后，下单请求先写入队列，后台慢慢处理，客户看到的是“订单处理中”，不影响体验。
// 队列削峰逻辑
public function placeOrder($orderData) {
// 1. 校验订单数据
$this->validateOrder($orderData);
// 2. 写入订单表
$orderId = $this->sa veOrder($orderData);
// 3. 推入队列，异步处理
Queue::push('ProcessOrder', [
'order_id' => $orderId,
'data' => $orderData
]);
// 4. 立即返回给客户
return ['order_id' => $orderId, 'status' => 'processing'];
}
总结：代购网站开发的核心不是“写代码”，是“管流程”
三年下来，最大的感受是：代购网站开发的技术难度其实不高，难的是把“人-钱-货-物流”这四件事用系统串起来。
- 库存同步解决“货”的问题
- 汇率缓冲解决“钱”的问题
- 自动对账解决“账”的问题
- 队列削峰解决“系统扛不扛得住”的问题
现在圈子里有个不成文的“鄙视链”：用系统的看不起用手工记的。不是看不起人，是手工真的扛不住。你一天二三十单的时候Excel够用，但做到日单几百的时候，没有系统，就是给自己挖坑。
