A systematic protocol to repro…

# 下单接口 NPE 排查与修复方案

一、先写复现测试（步骤 + 示例代码）

1. 收集现场信息

• 取该 500 错误的完整堆栈、requestId/traceId，找出报错请求的入参（下单参数）。
• 对比正常请求与失败请求的差异：通常是某些字段为 null（如用户地址、优惠券、库存快照等）。

2. 编写单测复现

```java

@SpringBootTest

class OrderServiceTest {

@Autowired

private OrderService orderService;

@Test

void shouldReproduceNpe_whenXxxIsNull() {

OrderRequest req = buildNormalRequest();

req.setXxx(null); // 根据堆栈推断的可疑字段

// 期望复现 NPE；修复后改为断言正常返回或抛业务异常

assertThatThrownBy(() -> orderService.createOrder(req))

.isInstanceOf(NullPointerException.class);

}

}

```

> 若 NPE 依赖并发/特定数据状态，用 @RepeatedTest(100) 或集成测试模拟真实数据构造。

二、定位思路（按概率排序）

1. 直接对象（最高概率）

• Map.get() 返回 null 直接调用方法：如 cache.get(userId).getLevel()。
• Optional 误用或链式调用：obj.getA().getB() 中 getA() 为 null。
• 数据库查询返回 null 未判空：如 userMapper.selectById(id).getStatus()。

2. 数据驱动型（偶发的典型原因）

• 只有特定用户/商品/渠道触发：老数据字段缺失、脏数据、逻辑删除记录。
• 用报错请求的参数在测试环境造数复现。

3. 并发问题（低频偶发需警惕）

• 缓存过期瞬间并发查询返回 null；双重检查锁不严谨。

三、修复建议

1. 短期（止血）

• 第 87 行加判空，将 NPE 转为业务异常 + 明确错误码（如“商品信息不存在”），避免裸 500。

2. 长期（根治）

• 入口校验：下单参数用 @Valid + JSR303 注解校验必填字段。
• 查询防御：DB/RPC/缓存查询结果统一判空或用 Optional 包装处理。
• 兜底监控：对该异常配置告警，保留 traceId 便于追踪。

四、验证清单

• [ ] 单测在修复前失败、修复后通过
• [ ] 补充边界用例：null 字段、空集合、不存在 ID
• [ ] 上线后观察数天，确认 500 归零

若方便贴出第 87 行附近代码与堆栈，可给出更精准的修复代码。