去年双十一那晚，我盯着后台差点把鼠标捏碎。

零点刚过，一款日本保温杯瞬间冲进来将近两百单。系统跑得稳稳当当，库存扣减丝滑流畅，我还在想今晚稳了。结果第二天一早，1688的采购员打电话过来，语气不太对：“哥，那款保温杯供应商说只剩十几件了，剩下的全都断货。”我当时脑子嗡的一声——两百单里将近八成没货。接下来的三天，客服挨个给客户退款道歉，几个老客户直接拉黑了我们，赔付加差评处理折腾掉差不多五万块。

后来查根因，发现1688那边的库存数据有5到30分钟的更新延迟。系统里显示还有五百多件库存，实际上供应商那边早就卖完了。我们的系统按本地数据放开了卖，结果就是超卖——卖出了实际上不存在的库存。大促期间流量一集中，这个延迟被放大到了灾难级别。

做了十年跨境电商，超卖这件事几乎每个代购团队都踩过。代购和普通电商不一样，你的库存不在自己仓库里，而是在1688、淘宝、品牌官网上。上游平台的数据延迟你根本控制不了，大促期间延迟只会更严重。你用本地库存数据去承接瞬时流量，超卖是早晚的事。

吃过那次亏之后，我花了不少时间研究防超卖的方案。市面上很多代购系统靠Redis锁来控制库存扣减，说实话这个思路没错——同一秒内只放一个请求通过，能避免并发冲突。但光有锁解决不了上游延迟的问题：你锁的是本地库存数据，而本地数据本身就是滞后的。锁得住并发，锁不住真实库存变动。

后来几个做技术的朋友一起聊，发现靠谱的做法是“限流缓冲”——把上游库存数据拉回来之后，不直接全部开放，而是按比例设置一个可售上限。比如1688显示还有一百件，系统前端只展示八十件，留二十件的缓冲空间。大促期间如果开启安全模式，这个比例还可以调得更保守。本质上是在用少卖几件的代价，去避免大批量退款和客户流失。Taocarts在这方面做了类似的设计，前端库存展示会根据品类和促销力度自动调整安全水位，运营后台可配，不用每次大促手动改。

另外一个补丁是库存差异预警。系统定时轮询上游数据，一旦发现本地库存和上游库存差距超过一定比例，自动标记该商品为“库存异常”，暂停接单并推通知给运营。不用等到采购员去下单才发现没货，事情发生之前系统就把问题暴露出来了。

算一笔账。那次双十一亏了五万，够买这套防超卖方案好几年的服务费。很多做代购的同行总觉得“系统差不多就行”，等出了事才开始算损失。超卖的隐性成本不仅是退款和赔付，真正贵的是客户不再回来。一个等了几天被告知缺货退款的客户，再次下单的概率低得可怜。你花几十块获客成本拉来的人，因为一次超卖就永久流失了。

经历了那次大促翻车之后，团队的采购和运营流程也做了调整。每次大促前运营会提前跟核心供应商确认库存深度，系统侧同步调高安全水位。大促前夜整个团队过一次应急流程，谁负责暂停商品、谁对接供应商、谁处理客户退款，都提前分好工。系统帮你发现了问题，剩下的事还是得人来兜底。

现在回头看，那次五万块的教训说贵也贵，说不贵也不贵——它逼着我把防超卖这件事从“靠采购员盯着”变成了“系统自动兜底”。做代购这行就是这样，坑填得差不多了，路才走得稳当。

做代购这一行，每笔退款背后都是信任的透支，客户没了就真没了。