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