引言：从“人肉选品”到“API锁款”
每年双11，选品都是电商运营最头疼的环节。过去我们靠运营同学手动刷后台、翻竞品、拉Excel，一个爆款从发现到确认往往要花上大半天。今年大促前，我们换了一套思路：把“选品—验证—锁款—铺货”这条链路全部用API串起来，最终在开战前锁定了100个高潜爆款。这篇文章就记录我们这次实战的完整过程，包括架构设计、核心代码和踩过的坑。整体思路：四个阶段锁定爆款
我们把整个流程拆成四个阶段，每个阶段对应一组API调用：
数据采集：通过商品API拉取大盘热销榜、新品榜和竞品店铺在售商品。
信号计算：对采集到的商品计算增速、收藏率、评价趋势等爆款信号分。
人工复核：把Top候选推送到内部审核系统，运营确认后进入锁款池。
库存锁定：调用库存API预占库存，并同步生成大促活动价。
整个流程每天跑两轮，双11前两周共锁定100个爆款，命中率比去年提升了约35%。
- 技术选型与架构
我们采用Java Spring Boot作为主服务，配合定时任务调度和消息队列做异步处理。整体架构如下：
flowchart TD
A[定时任务触发] --> B[商品API采集]
B --> C[信号计算服务]
C --> D[候选池]
D --> E[运营审核台]
E --> F[锁款API]
F --> G[库存预占+活动价]
G --> H[爆款池100个]
核心依赖包括：
商品查询API：获取销量、价格、上下架状态。
评价API：拉取好评率、评价增量。
库存API：查询可售库存并执行预占。
活动API：创建大促活动价。
- 核心实现：爆款信号计算
信号计算是整个系统的关键。我们给每个商品计算一个综合得分，由四个维度加权得到：
销量增速：近7天销量环比增长率，权重40%。
收藏率：收藏数除以浏览量，权重25%。
评价趋势：近3天新增评价数，权重20%。
价格弹性：当前价格相对近30天均价的折扣力度，权重15%。
下面是我们计算信号分的核心代码：
public class HotSignalCalculator {
private static final double SALES_GROWTH_WEIGHT = 0.4;
private static final double FAVORITE_RATE_WEIGHT = 0.25;
private static final double REVIEW_TREND_WEIGHT = 0.2;
private static final double PRICE_ELASTICITY_WEIGHT = 0.15;
public double calculate(ProductSignal signal) {
double salesGrowthScore = normalize(signal.getSalesGrowthRate(), 0, 3);
double favoriteRateScore = normalize(signal.getFavoriteRate(), 0, 0.2);
double reviewTrendScore = normalize(signal.getReviewIncrement(), 0, 200);
double priceElasticityScore = normalize(signal.getPriceDiscount(), 0, 0.5);
return salesGrowthScore * SALES_GROWTH_WEIGHT
+ favoriteRateScore * FAVORITE_RATE_WEIGHT
+ reviewTrendScore * REVIEW_TREND_WEIGHT
+ priceElasticityScore * PRICE_ELASTICITY_WEIGHT;
}
private double normalize(double value, double min, double max) {
if (value <= min) {
return 0;
}
if (value >= max) {
return 1;
}
return (value - min) / (max - min);
}
}
得分超过0.75的商品进入候选池，再由运营人工复核。
- 锁款流程：从候选到锁定
候选商品确认后，我们调用库存API执行预占。这里有一个关键点：预占不是直接扣减库存，而是先锁定可售库存，防止超卖。核心代码如下：
public class StockLockService {
private final StockApiClient stockApiClient;
public StockLockService(StockApiClient stockApiClient) {
this.stockApiClient = stockApiClient;
}
public LockResult lockStock(String productId, int quantity) {
StockQueryResult stock = stockApiClient.queryAvailableStock(productId);
if (stock.getAvailable() < quantity) {
return LockResult.failed("库存不足，当前可售：" + stock.getAvailable());
}
return stockApiClient.lockStock(productId, quantity);
}
}
锁库成功后，再调用活动API设置大促价，并把商品状态更新为“已锁款”。
- 踩坑记录与优化
实战中我们遇到几个比较典型的问题，这里分享出来供大家参考：
API限流：商品API有每分钟调用上限，我们一开始全量拉取经常触发限流。后来改成按榜单分页拉取，并加了本地缓存，调用量下降了60%。
数据延迟：评价数据有近1小时的延迟，导致信号分在高峰期波动较大。我们最终对评价增量做了滑动窗口平均，稳定性明显提升。
库存预占超时：大促前库存API响应变慢，预占经常超时。我们增加了重试机制和幂等键，避免重复锁库。
人工审核瓶颈：候选商品太多，运营看不过来。后来我们在审核台增加了排序和批量操作，单日处理量提升了一倍。
- 效果与总结
最终我们在双11前两周锁定了100个爆款，整体流程从原来的人工选品3天缩短到每天2轮自动扫描。大促当天，这100个爆款贡献了全店约45%的销售额，库存售罄率控制在合理范围，没有出现超卖。
这次实战最大的收获是：选品这件事完全可以标准化、自动化。API不是万能的，但把重复劳动交给系统，把判断力留给运营，效率和准确率都能上一个台阶。希望我们的经验能给大家的大促备战带来一些启发。如有任何疑问，欢迎留言探讨！
