会员商城平时订单不多时库存扣减很难暴露问题一旦某个商品短时间集中下单就可能出现库存变成负数或者两个人同时买到最后一件商品。代码里明明写了“库存大于零才能下单”实际还是会超卖原因通常出在查询和更新不是一个原子操作。排查这类问题我会先看订单创建时间再对照库存变更日志。如果几笔订单在很短时间内读取到相同库存基本可以确定是并发造成的。常见写法是先SELECT库存PHP判断数量足够后再UPDATE。两个请求同时查询时都可能认为库存还有一件后面的判断自然拦不住。处理时可以把判断放进UPDATE条件例如扣减时同时限制当前库存必须大于等于购买数量再根据受影响行数判断是否成功。订单创建和库存扣减需要放在事务里任何一步失败都回滚。对于秒杀一类高并发场景再考虑Redis预扣库存而不是所有商城都直接增加复杂度。库存日志也值得单独保留记录商品、订单、扣减前后数量和操作类型。退款、取消订单涉及恢复库存时同样要做幂等不能因为回调重复把库存加两次。库存问题表面上是一个数字减法真正需要保证的是多个请求同时进来时结果仍然正确。先把数据库条件更新、事务和日志做好通常比一开始就上复杂的分布式方案更容易维护。#会员商城 #PHP开发 #库存并发 #数据库事务