竞争条件查什么
竞争条件指并发场景下校验发生时序错位：两次请求几乎同时通过了“库存还有”“次数没用完”“券还没领过”的判断，于是限制被突破。高发功能是限次操作、库存扣减、优惠领取与核销、余额与积分。验证思路是用少量并发加最终状态核对，而不是压测——目标是证明幂等与原子性是否存在缺口。
基本信息
| 适用对象 | 限次功能、库存扣减、领取与核销、余额与积分 |
|---|---|
| 验证方法 | 测试账号 + 少量并发（如 3-5 路）+ 最终状态核对 |
| 观察信号 | 超出限制的最终状态、重复记录、数据不一致 |
| 止损要求 | 发现越限立即停止并恢复数据 |
典型使用场景
- 秒杀与限量活动上线前的并发校验核查
- 排查“一码多用”“一次领多份”类业务问题
- 验证分布式部署下锁的实现是否真正生效
- 评估退款、补发等补偿流程的并发安全性
- 为业务方提供可落地的原子化改造建议
验证步骤（测试环境）
验证步骤（测试环境）
1. 选带次数或库存约束的功能，确认基线状态（剩余数量、已用次数）
2. 用测试账号并发发送少量等价请求（先 3 路，再视情况加到 5 路）
3. 核对最终状态：限制是否被突破、是否产生重复记录、金额是否异常
4. 记录请求时序（时间戳）与最终状态截图，安排数据恢复
5. 结论区分“服务端未加锁”与“锁粒度不足”两类原因对象与并发风险
| 对象 | 并发风险 | 期望实现 |
|---|---|---|
| 库存扣减 | 超卖 | 数据库条件更新或分布式锁 |
| 领取类操作 | 重复领取 | 唯一约束 + 幂等键 |
| 次数限制 | 越限使用 | 原子计数与预占 |
| 余额与积分 | 重复扣减或加计 | 事务内校验并落库 |
| 核销与退款 | 重复核销 | 状态机 + 唯一业务键 |
并发验证会产生真实业务数据：限定测试账号、控制并发数、确保随时可回滚，并避开促销与业务高峰时段。
只在一台实例上验证不能代表集群行为：分布式场景下应确认锁是否落在共享存储（数据库、Redis）上，否则多实例部署时限制仍然可被突破。