时代网络
商城页面做得再顺滑，真正容易出事故的地方都在下单那几秒。几个设计选择，上线前必须定下来。
库存什么时候扣。 两种常见做法：下单时锁库存、支付成功后真正扣减，或者加购/下单就直接扣。前者要处理「锁了但没付」的释放，后者要处理「付了但库存不够」的退款。没有绝对正确的答案，但要跟业务确认：秒杀场景和普通零售，选法不一样。无论哪种，库存判断必须放在服务端，前端传过来的数量一律不信。
支付回调要按「会重复、会乱序」来设计。 支付平台通知可能重试、可能延迟、可能同一笔发两次。所以回调处理要做签名校验、做幂等（用平台流水号或订单号加状态判断，已处理过的直接返回成功）、把耗时动作放异步队列，别在回调里同步跑发货逻辑。回调接口还要返回平台要求的应答格式，不然它会一直重试。
订单状态机写全。 待支付、已支付、待发货、已发货、已完成、已关闭、退款中、已退款，每个状态之间谁能推进、什么条件推进、能不能回退，都要有明确规则。超时未支付自动关单并释放库存，这是一条必须有定时任务支撑的规则，别指望用户自己取消。
购物车也有几个隐形坑：商品价格要不要做快照（活动价变了，已加购的按哪个算）、下架商品怎么显示、用户登录前后加购的商品要不要合并。这些不写清楚，客服后期会被问爆。
最后，所有涉及金额和库存的操作都记日志。真出了对不上的单子，有日志能查，没日志只能靠猜。