关于购物车添加商品何时持久化的讨论

1.是，用当前订单 quantity + 历史订单 quantity <= 限购数量 来做检验。
2.直接入库。你想多了，可以说这基本没有什么压力的。防止恶意操作对单个用户 ratelimit 就行了。

1、显然是，否则限购可以被轻易绕过还有何意义？
2、请求压力大么？大么？大么？嫌大了加服务器啊，谁规定只能用一个数据库实例了？
再说，有人恶意增加压力的话，去商品下面去刷评论不是来得更快么？加购物车那点压力怎么不算啥

1、有这个疑问，应该是 产品 /运营需求 不明确导致的，限购分好几种：
a. 单 用户 /支付账户 /真人 限购（例如新人特惠商品）
b. 单 订单 限购（例如最近各家的 19.9 车厘子）
c. 从单纯限购拓展出的 首单特价 /折扣 or 首件特价 /折扣

具体采取哪一种限购，应该是从 产品 /运营需求 方面先明确好才对

2、这个怎么做都行，见仁见智。
项目小的话直接读写应该都没啥问题，反正后端那边自己也有读写缓存。
复杂点儿的我觉得 前端 先合并一下短时间（秒级）内的请求，Web 服务器 限制一下接口频率，后端再加个简单的限速，应该就足够应付大部分情况了。

似乎上一条回复中所有的"/"前都被加了空格，是在半角字符和全角字符之间强行加了分隔么？

测试：这,是.一-段 /没+有=空 a 格 1 的|话

一般来说，每次进入购物车页面的时候，都需要从后台重新获取购物车数据（获取购物车数据），其他页面加入购物车的时候，也是从后台接口（添加到购物车接口）返回实际数据，所以：
1.提交订单后，后台会把购物车中的相应商品从购物车删除
2.添加商品到购物车如果碰到限购超额，返回数据里面应该包括相关提示，由前端根据具体情况判断是否显示这条消息
3.关于缓存，只有在非购物车界面才会使用本地缓存但是跳转页面时会根据具体情况判断是否要刷新购物车数据
以上所谓的具体情况，应该由产品经理确认处理逻辑

- 关于限购数量，有两种方法：一是只在结账的时候判断，这种简单。另一种是放入购物车就先检测判断一次，这种会适当增加服务器开销，但可以通过缓存优化。但即便已经先判断一次，在结账时还是需要判断一次的。所以先判断一次仅仅是为了提高用户体验。

- 关于入库的问题，如果你的商品库存充足，也就是一般销售场景，那么何时入库都可以。就按最简单的方法就好，结账才入库。
如果是需要抢购的，类似于秒杀，几种方法：
1. 简单的就是结账时才入库，用户体验会差一些，因为放入购物车不一定购买成功。但如果只是用于单件商品抢购，推荐使用这种方法，也增加趣味性，因为抢购秒杀，就是比谁的手快，所以结账输入地址等信息这些都应该作为比快的环节。
2. 如果是多个商品抢购，那么放入购物车就应该入库，但增加超时时间。譬如可以设置普通会员 15 分钟超时，VIP 会员 30 分钟超时，白金会员 60 分钟超时。这种方法，与后台的通讯会增加一些些的服务器开销，但可以忽略。主要的压力是在于用户会不停的刷新页面，检查是否有其他用户释放的商品。
所以进一步的做法是，增加排队名单，用户没有抢到东西，自动加入排队名单，会自动定时检测位置，避免了用户手动刷新，也提高了用户体验。

@DeutschXP 结账时入库，结账的时候不是要把购物车的数据清理了么

@selrain #7
你问题里的 “入库” 指的是 “将购物车数据存入后端数据库” （讨论的是频繁读写购物车数据的问题）
他的 “入库” 指的是 “购买成功时核减库存” （讨论的是何时变更库存的问题）

不在一个频道上

@also24 是我理解错了么

这有什么好讨论的…