关于库存的扣减时机，其主流的做法分为了两种：

1.用户在客户端立即下单后，系统扣减（锁定）对应数量的库存；
2.用户在客户端立即下单，直至用户付款成功后，系统扣减（锁定）对应数量的库存；

对于第二个方案，我在之前的一个项目采用并实施了，但后面发现其实有一点非常不友好，就是如果人多同时对某一件商品下单，而它的数量又有限，即低于了购买数，那么就造成了用户明明成功下单并成功付款了之后却提示库存不足。而且更为麻烦的就是,一旦提示库存不足，后面又会涉及到退款，甚至如果在下单时使用了积分抵扣，还会牵扯到积分回滚等，所以这样一来反而把简单的问题复杂化了。

其实从产品的设计角度来说，两个方案无所谓对错与否，只要达到正确扣减库存的目的就行，但是从业务开发的角度来看，展开的功能点越多，其实你出错的概率也就越大，所以基于此，库存的锁定我是比较倾向于前者。

不过有人会问，按照第一种方案处理，会不会存在另一种情况，即用户客户端下完订单，后台成功扣减库存，但此时在支付界面，用户却取消了付款操作，至于用户何时再来付款，后台也是不知道的，所以这里也就形成许多无效单，造成库存占用，而真正想要购买的用户却无法下单，这样的情形显然是不行的。

怎么解决呢？我们可以设置一个定时任务，该任务专门来处理，久未付款的新订单，如果在一定的时间范围内（半小时），我们可将该订单的状态置为关闭。

以上便是本次项目，关于库存扣减时机的一点拙见，而且也具体落实到了项目开发中，如有设计缺陷的地方，再来补充。