长任务怎么异步化
超过同步等待窗口的任务要转异步：创建接口返回任务标识与状态地址，客户端轮询或订阅回调获取结果，任务本身用状态机管理排队、执行、成功、失败与取消。状态必须持久化，否则服务重启后任务凭空消失，用户只能重复提交。
基本信息
| 接口形态 | 创建返回 202 与任务标识，另提供查询与取消接口 |
|---|---|
| 状态机 | queued → running → succeeded 或 failed 或 canceled |
| 持久化 | 任务状态落库，重启后可恢复与续跑 |
| 进度反馈 | 提供进度百分比或阶段名，避免用户面对空白等待 |
| 超时 | 单任务设上限，超时转失败并保留日志 |
典型使用场景
- 长文档处理：一次分析几十分钟，同步接口必然网关超时
- 批量导出：任务式接口让用户先提交再取结果
- 多步骤流水线：每一步更新任务阶段，用户能看到进展
- 定时任务触发：由调度器创建任务并落库，便于审计
- 重试与取消：失败任务可重放，误提交的任务可取消
任务接口设计
任务接口设计
POST /jobs → 202 {job_id, status_url}
GET /jobs/{id} → {status, progress, result_url?}
POST /jobs/{id}/cancel → 202 {status: canceling}
状态机: queued → running → succeeded | failed | canceled
超时: 单任务上限 30 分钟，超时转失败并保留日志与部分结果
回调: webhook 需签名校验，失败按退避重投状态与客户端处理
| 状态 | 含义 | 客户端动作 |
|---|---|---|
| queued | 已受理待调度 | 按退避间隔轮询 |
| running | 执行中 | 展示进度，允许取消 |
| succeeded | 完成 | 取结果并停止轮询 |
| failed | 失败 | 展示原因与是否可重试 |
| canceled | 已取消 | 不再轮询，释放本地状态 |
轮询间隔要退避：固定秒级轮询在任务多的时候会自己制造一波查询压力，把异步化的收益抵消掉。
任务要有归属：记录创建者与来源渠道，否则堆积任务无法判断该通知谁，也无法在配额紧张时决定先停哪一类。
结果要设有效期：结果文件与外链长期有效会把存储和权限管理变成长期负担，到期删除并提示用户重新提交更可控。