为什么购物车里的商品一会儿显示失效、刷新一下又有货？为什么凑单算好的优惠，提交时提示商品状态变了？问题大多不在商品，而在代理IP 出口没有扛住购物车里那一连串实时校验请求。
购物车不是一个静态清单
购物车看着是个清单，实际上是持续在跑请求的：加入购物车、修改数量、勾选与取消、删除、移入收藏，每一步都是一次写操作。打开购物车时，客户端还会对清单里每件商品重新问一次库存和价格，这些请求同样走代理IP 出口。
库存和价格每次进购物车都要重新问一遍
商品页上看到的库存属于那一刻的快照，购物车里的库存是重新查出来的。这就要求出口在购物车打开时保持稳定：抖动一次，某几件商品查不到结果，界面就显示失效或者状态未知，其实商品还好好的。
跨店凑单把好几条请求叠在一起
凑单是电商里最考验链路的操作之一。满减门槛往往要跨几家店的商品一起算，每家店的库存、价格、可参与活动都要单独查询，几条请求几乎同时发出。代理IP 出口带宽不足时，先发的返回了后发的还在排队，算出来的优惠和实际情况对不上。
失效商品是另一类常见情况。商品下架、规格变更、活动结束都会让购物车内条目失效，这类状态靠查询返回。出口抖动时查询超时，条目既没显示失效也没显示正常，一直悬在中间状态，用户不知道该删还是该留。
购物车里的配送时效和库存同样按地区展示。出口地区与收货地区一致时，看到的可配送信息和库存才准确；出口地区错位，会出现这件显示有货那件显示无货、配送时效前后不一致的情况。
- 结算前固定出口，让清单内所有商品的库存价格在同一会话内查完
- 凑单期间不要切换出口，几家店的查询结果要落在同一口径上
- 遇到失效提示先确认出口稳定再刷新，排除链路问题后再处理商品
- 大促集中加购错峰进行，避开商品页与购物车同时抢带宽的时段
大促和秒杀开场前后的几分钟，是购物车压力最大的时候。大量用户同时加购、同时刷新，库存接口的响应明显变慢。这时候最容易出现「明明还有货却提示抢完」的现象。错峰加购、提前把商品放进购物车，能避开这段拥堵。
多设备使用同一个购物车也很常见：手机加购、电脑结算。两台设备走同一个代理IP 出口，清单内容才能同步；一端固定一端乱跳，会出现手机删掉了电脑还在、电脑改了数量手机没变的情况。
收藏夹和购物车是两套机制。收藏夹保存的是商品标识，加载压力小；购物车要实时查库存价格，请求重得多。把暂时不买的商品放进收藏夹，能减轻购物车每次打开的校验压力。
凑单清单和凑单提醒是辅助功能，会定期拉取可凑单商品。这类请求频率不高但对连续性有要求，代理IP 出口稳定时清单内容完整，抖动时清单缺几条，凑单建议就不完整，看着像少算了优惠。
批量修改数量是一次性提交多条写请求。数量改得多，请求就多，代理IP 出口带宽不足时后面的请求排队，出现前几件改成功了后几件没生效的结果，清单里的数量和实际提交的不一致。
购物车还有一层缓存机制：短时间内重复打开，部分数据来自本地缓存。出口频繁变化时，缓存里的数据和服务器返回的对不上，界面上就会出现失效与有货来回跳的现象。
回到开头那两个问题：商品一会儿失效一会儿有货，多半是库存查询请求没跑完整；凑单优惠对不上，多半是几家店的查询没落在同一条出口上。把代理IP 出口在结算前固定住，这两类情况会少很多。