PDP 到订单生成的第一步：用户点了啥？

先说说这玩意儿叫 PDP，产品详情页。

用户刷到这儿，眼睛一亮。

“哎呀，这件宝贝不错”。

于是点了个「立即购买」按钮。

哈哈，这一步kan似简单，实则暗藏玄机。

点完按钮，前端立马把商品 ID、规格、数量、用户 ID 打包成一个 JSON。

然后往后端扔过去。

不对不对，我说的应该是「发送请求」geng贴切。

这个请求里还会带上当前的营销活动码、优惠券信息。

Ru果有会员折扣，那也一起塞进去。

懂吧？就像你逛街时顺手把钱包、手机和购物清单一起放进口袋。

服务器收到请求后第一件事就是校验签名。

别忘了安全啊，别让黑子来捣乱。

签名通过就继续往下走；不行的话直接返回错误，让前端弹个提示框——“参数异常”。

紧接着，系统会去查询商品库存。

Ru果库存不足，那就返回「缺货」；Ru果够，那就锁库存。

这里的锁库存不是写死的，而是写进一条临时记录——叫「预占」或者「冻结」库存。

这一步hen关键，因为后面可Neng会出现并发抢购的情况，你懂的，抢票那套流程差不多。

锁好库之后就轮到生成订单号了。

大多数系统采用时间戳+机器码+自增序列的组合方式。

比如「20230606」+「01」+「000123」。

这样既保证唯一，又Neng追溯来源机器。

有些公司喜欢在订单号里埋业务信息，比如渠道码、业务线标识。哈哈，这玩意儿叫「业务透传」。

下面要把订单主表、订单明细表以及预占库存表一起写进去。

这一步必须在同一个事务里完成，否则万一中间挂掉，会导致数据不一致——订单存在但库存没锁住或者相反。你懂的，就是那种尴尬局面。

所以代码里会这么写：

// 开启事务
BEGIN;
INSERT INTO order_main ;
INSERT INTO order_detail ;
UPDATE stock SET locked = locked + qty WHERE sku_id = ...;
COMMIT;

别忘了异常捕获，一旦出错，就回滚，确保系统干净如新。

PDP 点完买单按钮后还会触发一些后台任务——比如记录用户足迹、推送营销事件、geng新缓存。说白了就是让系统跑几个小脚本，不影响主流程，但Neng提升体验和数据完整性。

把用户 ID、商品 ID、时间戳写进日志表或 ES 索引；

以后Zuo推荐或复购分析就靠这些数据啦；

Ru果这件商品参与满减或秒杀，需要通知优惠服务去计算是否满足条件；

有时候还要给用户发站内信提醒：“您Yi成功加入抢购队列”。

PDP 完成下单后页面会跳转到支付页或者弹起支付弹窗，这一步叫「支付准备」。

PDP 页面拿到刚才生成的 order_id；

PDP 把 order_id 发给前端 JS；

前端再调用统一下单接口，把金额、商户号等信息塞进去；

AFAIK，它负责生成一个第三方平台Neng识别的交易凭证：

wx 的 prepay_id；

ZhiFuBao 的 trade_no；

a）前端按钮要防抖或一次禁用；

// 根据唯一请求标识判断是否Yi创建订单
SELECT id FROM order_main WHERE client_token = ?;

CACHE 锁：在 Redis 里先 setnx 锁定 SKU，再扣库存；

CANCEL 机制：若支付未完成，在一定时间内自动解锁库存。

A) 使用消息队列持久化回调数据；

B) 回调处理必须幂等——根据 payment_id 判断是否Yi处理过。

PDP 按钮触发前端请求

P2: 库存查询与锁定