首先是商品库存变动带来的一系列边界问题，这也是购物车模块最高发 bug 来源。购物车仅仅是对商品的预收藏，并不锁定库存，这是绝大多数电商系统的底层规则，这就会催生多种边缘状态。第一种场景，用户将商品加入购物车之后，商品库存逐步降低直至归零，此时购物车本地列表仍然保留这条记录。如果没有做实时校验，页面依旧可以勾选该商品，进入结算页面才提示无法下单，会给用户带来困惑。还有一种细分情况，购物车内商品数量大于当前可售库存，例如用户之前加入 5 件商品，后续其他用户下单消耗库存，剩余可售只有 2 件，购物车本地还保留 5 的数量。此时若直接放行到下单接口，要么接口报错中断流程，要么出现超卖问题。部分实现只在提交订单瞬间校验库存，购物车列表页面不做处理，用户看到自己购物车里的数量，却无法按该数量购买，交互逻辑断裂。还有库存动态变化过程，多用户并发操作同一件商品，库存短时间内反复增减，小程序前端缓存的购物车数据和后端实时库存不同步，页面展示状态滞后。
针对库存相关边界，不能只依靠下单环节做拦截。在打开购物车页面、修改商品数量、勾选商品的时候，都需要同步拉取商品最新库存状态。当购物车内存储的购买数量超过实时库存，系统应当自动修正可购买数量，同时给出文字提示，告知用户可购买的最大数量，而不是直接置为 1 或者直接隐藏条目。库存为 0 的商品条目，不应该直接删除用户购物车记录，要做失效标记，置为不可勾选状态，保留原有记录，让用户能够手动移除；如果直接后端删除购物车数据，会出现用户再次打开购物车，自己之前保存的商品莫名消失，属于严重体验 bug。同时要区分库存为零和商品下架两种状态，二者逻辑不能混淆。
第二大类边界，商品基础信息变更后的购物车数据兼容问题。商品加入购物车时，前端会缓存一部分商品快照信息，包含规格图片、规格名称、单价等内容。后续后台对商品进行编辑修改，就会和用户购物车内旧快照产生冲突。比如修改规格售价，后台调高或者调低单品价格，购物车本地缓存还是旧的价格，页面展示价格和结算接口返回价格不一致，就出现前端显示总价和提交订单总价对不上的 bug。用户看到购物车显示的金额，到结算页金额发生变化，很容易产生误解。还有规格信息修改，原有规格被后台删除、禁用，或者规格参数名称改动，购物车中保存的是旧规格 id，打开购物车无法匹配到有效的规格数据，出现条目空白、名称缺失、图片不展示，部分代码未做空判断，甚至直接导致整个购物车页面渲染崩溃。
除此之外还有商品整体下架、隐藏的边界，商品被设置为下架状态，购物车记录依旧存在。很多开发逻辑会直接过滤掉下架商品，不在列表渲染，用户完全看不到这条购物车数据，但数据库中这条记录还存在，统计购物车商品总数的时候，还会把这条已经失效的数据计入总数，就会出现购物车角标数字，点进去却看不到商品的经典 bug。处理这类场景的核心思路，购物车不应该完全依赖本地存储的快照做最终数据渲染，每次加载购物车列表，都要根据存储的商品 id、规格 id 向服务端获取最新商品元数据。对已经找不到对应规格、商品已下架的条目，打上失效标签，单独分组展示，允许用户批量清理失效商品。价格展示优先使用接口返回的实时价格，本地快照只用作兜底展示，结算金额完全由后端计算，前端只负责渲染，禁止前端直接计算最终价格，避免篡改和计算偏差。
第三是数量操作的各类边界条件。用户对购物车商品数量进行增减操作，这里有很多容易遗漏的判断。首先是数量下限，最少购买数量，不能无限制减到 0 以下，点击减号，数量到 1 之后，再次点击，不同业务有两种逻辑，一种是数量保持 1，另一种是弹出确认弹窗，确认是否删除该商品。如果缺少判断，会出现数量变成 0、负数的脏数据，进而导致价格计算异常。其次是上限边界，分为单规格最大可购买数量、购物车单条记录上限。部分商品设置限购，比如每用户最多购买 3 件，用户购物车内已经存放 3 件，继续点击加号，应当拦截操作并提示限购信息，若没有拦截，会生成超过限购的数量，直到下单才报错。还有一个容易忽略的点，批量操作场景，批量勾选之后批量修改数量，多条商品同时变更，并发请求处理不当，会出现部分商品数量更新成功，部分更新失败，前后端数据不一致。
小程序端还存在本地缓存和后端存储同步的边界。小程序购物车一般分为两种存储模式，未登录状态下，购物车数据保存在小程序本地存储；登录之后，需要把本地购物车数据合并到服务端。登录合并逻辑是 bug 高发区。当本地和后端同时存在同一款规格的商品，合并的时候，是数量相加，还是以哪一方的数据为准，如果逻辑处理错误，会出现重复生成购物车条目，同一件商品出现两行记录。还有登录状态切换，退出登录之后，服务端的购物车数据隐藏，展示本地未登录购物车，再次登录又重新拉取服务端数据，状态切换过程如果没有清空页面内存数据，页面会残留上一个账号的购物车内容，出现数据串号。未登录状态下本地存储有容量限制，存储的购物车条目过多，超出小程序本地存储上限，新增商品失败，没有捕获异常，用户点击加入购物车，页面看起来成功，实际刷新之后商品消失，用户感知就是加不进购物车。
第四类边界是勾选逻辑与价格汇总计算边界。全选、反选、部分勾选，是高频交互，这里容易出现状态不同步 bug。比如列表内存在多条失效、不可勾选的商品，执行全选操作的时候，代码如果简单遍历全部条目勾选，会尝试勾选失效商品，勾选状态 UI 错乱，全选框状态判断出错：明明还有可勾选商品没有选中，全选框却显示选中；或者存在不可选商品，全选按钮点击之后全部勾选，把失效条目也纳入价格统计。价格汇总逻辑上，选中商品的合计金额，不能简单直接累加前端页面上展示的单价乘以数量。遇到商品参与活动、限时折扣、会员价等场景，单品实际结算价不等于展示售价。如果前端自己做总价计算，接口返回的真实结算总价和前端算出来数字不一致。同时要处理选中商品全部失效的场景，所有勾选条目全部失效，合计金额归零，结算按钮置灰禁用，不能允许用户提交空的有效商品去下单。
批量操作同样有边界，批量删除购物车商品，网络请求失败，用户重复点击删除按钮，重复发起请求，造成多次删除或者部分条目删除失败。还有批量勾选之后点击结算，如果勾选的商品全部失效，没有前置校验，直接跳转到结算页面，结算页没有有效商品，出现空白页面。
第五，网络异常、页面生命周期带来的边界 bug。小程序有页面销毁、后台休眠、网络中断的场景。用户修改购物车商品数量，点击加号之后网络断开，前端页面数量已经 + 1，后端没有更新，页面和数据库数据不一致。重新切回购物车页面，没有重新刷新接口，一直展示错误状态。小程序下拉刷新购物车，同时用户正在操作数量增减，多个接口并行请求，接口返回顺序错乱，旧接口晚于新接口返回，把页面数据覆盖回旧状态，造成状态回退 bug。部分开发仅在页面 onShow 的时候拉取一次数据，页面常驻缓存，其他终端修改了同一账号的购物车，当前小程序不会感知，必须每次进入购物车视图都请求最新服务端数据。
除此之外，还有一些小众但真实存在的边界。比如同一个商品不同规格同时存在购物车内，修改其中一条规格的状态，不要影响其他规格条目；购物车条目数量很多，分页加载场景，全选操作只选中当前分页展示的商品，而不是全部购物车商品，逻辑错误会造成用户以为全部勾选，实际只有当前页商品被选中。
想要降低购物车模块线上 bug，开发阶段就要跳出正常使用流程，主动模拟各类边界。核心原则可以总结为几点：所有和库存、价格、商品有效性相关的判断，后端做权威校验，前端只做交互拦截和提示，不把业务规则完全交给前端；区分本地缓存和服务端数据源，登录前后数据合并逻辑做好去重；对失效商品单独处理，不直接删除用户记录；对数量、勾选状态做好完备的上下限判断；处理好网络异常、接口并发、页面生命周期，防止数据错乱。购物车模块看起来逻辑简单，但大量边界场景藏在日常使用之外，只有把这些边缘条件全部纳入逻辑设计，才能减少线上异常，保证模块稳定运行。
联系电话