11、订单异常诊断：缺货、超卖、风控拦截、支付失败

订单异常，说白了就是用户下单流程中突然「卡住」了。我见过太多团队只盯着GMV看，结果订单异常率飙到5%以上还不自知。今天咱们就聊聊四种最常见的订单异常：缺货、超卖、风控拦截、支付失败。每一种我都踩过坑，咱们一个一个说。

11.1 缺货：库存明明有，为啥发不出？

缺货不是「没库存」那么简单。我遇到过一种情况：系统显示库存100件，但实际仓库里只有80件。为什么？因为库存数据没同步。

缺货的常见原因：

• 多仓库存不同步：A仓有货，B仓没货，但系统统一显示有货
• 预售与现货混卖：预售订单占用了现货库存
• 库存锁定机制缺失：下单时没锁定库存，导致超卖后缺货

-- 库存异常诊断SQL示例
SELECT 
  sku_id,
  SUM(CASE WHEN type = '入库' THEN quantity ELSE 0 END) as total_in,
  SUM(CASE WHEN type = '出库' THEN quantity ELSE 0 END) as total_out,
  (SELECT stock FROM inventory WHERE sku_id = i.sku_id) as system_stock
FROM inventory_log i
WHERE date >= '2024-01-01'
GROUP BY sku_id
HAVING total_in - total_out != system_stock;

11.2 超卖：系统说卖了200件，实际只有100件

超卖是电商最头疼的问题之一。说白了就是「卖出去的比库存多」。为什么会这样？

超卖的三大元凶：

1. 高并发下库存扣减没加锁：两个请求同时读到库存=1，都以为能卖
2. 缓存与数据库库存不一致：Redis显示有货，MySQL显示没货
3. 异步扣库存导致延迟：订单创建了，库存还没扣

我的诊断流程：

• 第一步：查「订单创建时间」和「库存扣减时间」的时间差
• 第二步：看同一SKU在1秒内的并发订单数
• 第三步：对比「支付成功订单数」和「实际发货数」

-- 超卖检测SQL
SELECT 
  sku_id,
  COUNT(DISTINCT order_id) as order_count,
  MAX(stock_before) as max_stock
FROM order_sku_snapshot
WHERE create_time BETWEEN '2024-01-01 00:00:00' AND '2024-01-01 00:01:00'
GROUP BY sku_id
HAVING order_count > max_stock;

11.3 风控拦截：用户没违规，为啥被拦？

风控拦截，说白了就是系统觉得「这笔订单有问题」。但很多时候，误杀率比命中率还高。我遇到过最离谱的案例：一个老用户连续买了3天奶粉，结果被风控判定为「刷单」。

风控拦截的常见误杀场景：

• 新设备登录老账号：换手机后第一次下单，被拦截
• 短时间内多笔同地址订单：帮同事代购，被判定为刷单
• 高客单价商品频繁下单：买手机被拦截，因为风控觉得「太贵了不像真的」

-- 风控拦截分析
SELECT 
  risk_rule_name,
  COUNT(*) as intercept_count,
  SUM(CASE WHEN is_mistake = 1 THEN 1 ELSE 0 END) as mistake_count,
  ROUND(SUM(CASE WHEN is_mistake = 1 THEN 1 ELSE 0 END) * 1.0 / COUNT(*), 2) as mistake_rate
FROM risk_intercept_log
WHERE date = '2024-01-01'
GROUP BY risk_rule_name
ORDER BY mistake_rate DESC;

11.4 支付失败：用户付了钱，系统没收到

支付失败，嗯，这里要注意。它分两种：一种是用户确实没付成功，另一种是用户付了但系统没收到回调。后者最坑人。

支付失败的典型场景：

• 银行扣款成功，但回调超时：用户以为付了，系统显示未支付
• 支付密码错误多次被锁：用户急了，直接放弃
• 第三方支付接口异常：比如支付宝或微信的接口挂了

我的诊断思路：

• 第一步：区分「用户主动取消」和「系统支付失败」
• 第二步：查支付回调日志，看是否有「支付成功但未通知」的情况
• 第三步：对比「支付渠道返回码」和「订单状态」

-- 支付失败分析
SELECT 
  payment_channel,
  return_code,
  COUNT(*) as fail_count,
  SUM(CASE WHEN order_status = 'paid' THEN 1 ELSE 0 END) as actual_paid
FROM payment_log
WHERE status = 'fail'
  AND date = '2024-01-01'
GROUP BY payment_channel, return_code;

11.5 四种异常的关联分析

你想想看，这四种异常其实经常「串在一起」。比如：

• 超卖导致缺货 → 用户投诉 → 风控误判为恶意订单 → 拦截 → 用户支付失败
• 支付失败 → 用户重试 → 库存没释放 → 超卖

我习惯用一张「异常关联图」来梳理。下面是我自己画的逻辑图：