# 历史典型缺陷复盘

> 这些是过去项目中发生过的真实 Bug，生成新用例时，请针对这些逻辑设计防御性测试用例。

### 缺陷 ID: BUG-202310-05
- **模块**: 购物车
- **描述**: 商品降价后加入购物车，随后商品恢复原价，结算时依然按降价后的价格计算，导致资损。
- **根因**: 购物车缓存了价格，结算时未重新从商品中心获取最新价格。
- **防御用例**: `验证商品加入购物车后，后台修改价格，结算时系统自动更新为最新价格`。

### 缺陷 ID: BUG-202311-12
- **模块**: 优惠券
- **描述**: 使用“满100减50”优惠券购买 100 元商品，退货时未扣除优惠金额，导致用户获利。
- **根因**: 退款逻辑未考虑优惠分摊。
- **防御用例**: `验证使用优惠券购买多件商品后，部分退款时优惠金额按比例扣除`。

### 缺陷 ID: BUG-202312-07
- **模块**: 下单接口
- **描述**: 调用下单接口时，通过篡改请求参数，将商品数量改为负数，系统未做边界校验，使订单总金额变为负数，用户支付后平台产生负向应收，造成资损。
- **根因**: 下单接口对商品数量仅做了非空校验，未校验正整数及防止整数溢出。
- **防御用例**: `验证调用下单接口时，传入商品数量为 0、负数、超大整数（如 9999999）时，系统均能拦截并返回错误码，不生成有效订单`。

### 缺陷 ID: BUG-202401-15
- **模块**: 支付网关
- **描述**: 用户下单时选择“普通订单”（应付金额 100 元），在调起支付前通过抓包修改支付接口请求参数，将支付类型从“微信支付”改为“全额积分支付”。由于后端未校验订单原始支付方式，积分系统扣除了用户 100 积分（1 积分=1 元），用户实际未付现金即获得商品。日损失积分资产超 10 万。
- **根因**: 支付接口仅校验了用户积分余额是否充足，未与订单核心表中的支付方式快照做一致性校验。
- **防御用例**: `验证下单时选择现金支付，支付阶段强制改为积分支付或余额支付时，后端应校验请求支付方式与订单生成时记录的支付方式一致，不一致则拒绝支付`。

### 缺陷 ID: BUG-202401-22
- **模块**: 并行扣减
- **描述**: 秒杀活动中，用户通过多线程并发调用下单接口（同一商品 ID，同一用户），由于缺少分布式锁或乐观锁，导致同一件商品被同一用户成功下单 3 次，库存扣减超出实际售卖数量，产生超卖资损。
- **根因**: 库存扣减 SQL 为 `update stock set count = count - 1 where product_id = ?`，未使用 `and count > 0` 条件，且业务层未做幂等和并发控制。
- **防御用例**: `验证同一用户对同一限购商品发起 10 次并发下单请求，最终只成功创建 1 个订单，库存扣减 1 件`。

### 缺陷 ID: BUG-202402-03
- **模块**: 价格计算
- **描述**: 商品 A 单价 50 元，参与“满 2 件打 8 折”活动。用户将 1 件加入购物车，下单前活动变更为“满 3 件打 7 折”，但前端仍展示旧折扣，提交订单时后端沿用旧活动的价格计算规则，导致用户少付。
- **根因**: 后端未在订单入库前重新计算促销活动价格，而是信任前端传入的活动 ID 和已优惠金额。
- **防御用例**: `验证商品促销活动变更后，用户使用旧的活动 ID 提交订单，系统应抛弃前端传入的优惠信息，强制重新计算最新活动价格`。

### 缺陷 ID: BUG-202402-18
- **模块**: 退款/逆向流程
- **描述**: 用户使用混合支付（现金 80 元 + 余额 20 元）购买 100 元商品。申请全额退款时，退款逻辑先调用余额退款接口（退还 20 元），然后调用现金退款接口（退还 80 元）。但现金退款接口因网络超时返回失败，系统记录退款失败，但实际上余额的 20 元已退给用户，用户凭空获利。
- **根因**: 退款流程未使用分布式事务或 TCC 模式，分步调用外部接口出现部分成功时无法回滚。
- **防御用例**: `验证混合支付全额退款时，若现金退款接口调用失败，系统应能自动回滚已退的余额部分，或保持整体失败状态，绝不出现部分退款成功`。

### 缺陷 ID: BUG-202403-11
- **模块**: 价格篡改
- **描述**: 用户将商品加入购物车后，通过浏览器开发者工具修改页面中某个商品的“单价” DOM 元素（从 100 改为 0.01），提交订单时后端未校验单价，直接使用前端传回的 0.01 元创建支付单，用户以 1 分钱买走商品。
- **根因**: 下单接口设计时错误地将商品单价作为可信任的入参，未从商品中心重新获取真实单价。
- **防御用例**: `验证所有与金额、价格、数量相关的核心字段（单价、总价、运费等）均不能信任前端传入，下单时后端必须独立从商品库/价格服务中重新获取并计算`。

### 缺陷 ID: BUG-202403-20
- **模块**: 重复支付
- **描述**: 用户在支付网关点击“确认支付”按钮后，由于网络延迟前端未收到回调，用户连续点击 3 次，系统生成了 3 个相同的支付请求（同一订单号），三方支付渠道返回 3 个不同的交易单号，且订单系统最终对同一订单进行了 3 次金额累加，多收了用户 2 份钱。
- **根因**: 支付接口未做幂等性校验，允许同一订单号多次发起支付请求并修改订单状态。
- **防御用例**: `验证同一订单号在 1 秒内收到 5 次相同支付请求，后端仅处理第一次请求，后续请求直接返回“处理中”或“重复请求”，订单状态不被多次累加`。

### 缺陷 ID: BUG-202404-02
- **模块**: 积分与现金互转
- **描述**: 活动期间积分可抵扣现金（100 积分 = 1 元）。用户下单时使用 5000 积分抵扣 50 元，订单总金额 100 元，实付 50 元。后续用户申请全额退款，系统退还了 5000 积分 + 50 元现金，相当于积分被重复退还（原积分未核销），用户用 0 成本套取 50 元现金。
- **根因**: 退款时未先扣回已使用的积分（或积分已被消耗），而是直接重新发放等额积分。
- **防御用例**: `验证使用积分抵扣部分现金后，申请退款时应先原路返还积分（若积分未过期）或按比例折算成现金，确保平台不产生额外资产损失`。