批量任务不是"循环调用"
把单条功能套个循环就是批量 ✗ —— 上线后立刻遇到四个问题 ✗：
排队与限流怎么处理 ✔、进度怎么给 ✔、失败怎么重跑 ✔、花多少钱先说清 ✔。
**批量任务是独立的产品形态** ✔，要单独设计 ✔。
一、四个必备能力
**① 排队与限流**
任务进队列，**并发可控** ✔（避免把上游打爆 ✔ —— 见限流那篇 ✔）；
给用户**队列位置与预计等待** ✔（见容量那篇 ✔）；
支持**优先级**（交互式请求优先于批量 ✔）。
**② 进度可见**
```
已完成 42 / 100 ｜ 失败 3 ｜ 预计剩余 6 分钟
```
进度要**按条**（不是百分比估算 ✔）；
**可暂停/取消** ✔（长任务必须能停 ✔）；
页面关掉也能继续 ✔（服务端执行 ✔ —— 见状态与恢复那篇 ✔）。
**③ 失败可重跑**
**只重跑失败项** ✔（别把成功项再跑一遍 ✗ —— 白花钱 ✔）；
保留每条的**失败原因** ✔（可导出 ✔）；
支持人工修正后重跑（见人工审核那篇 ✔）。
**④ 成本透明**
**提交前给预估**（条数 × 单条估算 ✔）；
**超预算要确认** ✔（见价格与额度那篇 ✔）；
完成后给**实际消耗** ✔。
二、结果的组织方式
**可导出**（CSV/JSON，中文 CSV 带 BOM ✔ —— 见导出那篇 ✔）；
**可对比**（同一批次前后版本的差异 ✔）；
**可抽样复核**（人工抽检入口 ✔ —— 见审核队列 ✔）。
三、三个反模式
**前端轮询到页面关闭就断** ✗（任务其实还在跑，用户以为失败了 ✔）；
**一条失败就整批失败** ✗（浪费已完成的 ✔）；
**没有预估就开跑** ✗（账单惊吓 ✔）。
四、一条判据
> 提交 1000 条批量任务后 ✔，用户能否知道"进行到哪、花了多少、失败几条、怎么只重跑失败项" ✔？
> 缺任一项，说明批量只是循环调用 ✗。