本节摘要:从"加入购物车"到订单流转进仓库,中间隔着购物车的结算逻辑、订单状态机、库存扣减策略三台机器。本节讲清每台机器的运转原理与常见故障——超卖、挤占、待付款堆积——并给出对应的设计取舍。
如果说详情页是转化的艺术,本节就是转化的工程。用户感受不到这三台机器,但每一次"付款失败""显示有货却发不出""订单自动取消",都是机器故障直接漏掉的成交。
购物车至少承担四种职能,每种都直接影响转化:

订单的一生是一张状态机:待付款、已付款、待发货、已发货、已签收、已完成,加上取消、退款中、已关闭等分支。状态机设计的核心不是正向流程——那很简单——而是每个状态的驻留上限与超时动作:
三条例外的设计经验:其一,支付回调要有对账兜底——用户已扣款但回调丢失,订单停在待付款,若被超时关闭就成了客诉重灾区,所以支付系统必须有主动查询与对账补偿(第四章展开)。其二,风控要卡在付款后、发货前:可疑订单(地址异常、设备风险)在出库前拦截,成本最低。其三,售后期结束才置"已完成",因为评价与逆向售后都挂在这个窗口里。
订单本身是一份结构化契约,核心字段在系统间的流转都围绕它展开:
{ "order_id": "2026090588600127", "status": "PAID", "buyer_id": "u_88012", "items": [ { "sku_id": "grinder-std-ss", "title": "手动咖啡研磨器 标准版", "qty": 1, "price_paid": 16900, "promotion_id": "bundle-902" } ], "amounts": { "goods": 16900, "discount": 0, "freight": 0, "paid": 16900 }, "payment": { "channel": "WALLET", "trade_no": "pay_9931x", "paid_at": "2026-09-05 21:04:11" }, "snapshot": { "warehouse": " WH-EAST-2 ", "stock_deducted": true }, "timeline": { "created": "21:02:47", "paid": "21:04:11", "ship_by": "48h" } }
注意 amounts 与 snapshot 两组字段:前者是资金口径的完整留痕(分摊到每一笔优惠),后者是履约承诺的锚点(从哪个仓、何时承诺发出)。售后纠纷调解时,这两组字段就是证据链。
库存管理的第一定律:前端显示的"有货"必须与后端可承诺库存一致。不一致有两种表现,都致命——显示有货实际无货(超卖,发货违约、批量赔付),显示无货实际有货(少卖,白白漏单)。超卖的根源是并发:一百个人同时下单最后一件商品,若扣减不加控制,一百个订单都会成立。
工程上两条路线:
平台型卖家还有一层"可售库存 = 在库库存 − 锁定库存 − 在途调拨"的承诺口径计算,任何一层口径错了,前端显示就会系统性漂移。运营侧的对应动作是安全库存:为销量波动留缓冲,安全库存量通常按"日均销量乘以补货周期"再叠加波动系数估算,断货对转化的伤害不只是漏单——搜索权重会随断货下滑,重新上架后的爬坡要花几倍于断货期的时间。
机器运转起来了,现在需要仪表盘:转化率到底哪一层在漏?下一节把漏斗装上数字。