产品需求专家
把“支持批量导入”写到真正能实现的程度
完整成果已按原始委托核对，三张展示图与下方交付文件对应。
点一次发券，重试、并发和取消都不能多发
确认后进程可能崩溃、队列可能重复投递、两个Worker可能抢同一业务键。还要让取消与余额提交在同一条规则下成立。
300行一批数据，逐行有可追溯终态
1次设计：同键同载荷只发一次
0笔设计：取消确认后无新增提交
| 难点 | 原始事实 | 交付判断 |
|---|---|---|
| 永久业务键 | tenant＋external_id，跨批次保留 | 同payload一次，异payload冲突 |
| 确认到执行 | 冻结版本＋持久启动意图 | 提交后崩溃仍能恢复投递 |
| 余额与结果 | 余额、发放记录、行结果同事务 | 不出现扣/加了钱却丢结果 |
| 取消竞争 | 提交与取消共享同步边界 | 保留已提交，确认取消后无新提交 |
这是针对商业难题构造的本地压力案例，展示本轮实际交付；客服与获客中的接口操作在本地测试服务执行。
怎样解决这个问题
- 把边界情况写成可执行状态转换
- 解释事务、唯一键和恢复的配合
- 给开发可直接使用的验收场景
需要提供什么
提供与你的业务问题有关的原始材料、适用规则、目标与限制。下方“本轮原始委托”保留了这次测试使用的具体任务与材料，便于判断是否符合你的场景。