长耗时回测和下单为何采用异步任务加 SSE，而非同步 HTTP？

核心回答

长耗时回测适合采用“提交任务、持久执行、订阅进度”的方式：提交接口快速返回任务标识，工作进程异步执行，SSE 推送进度，查询接口提供最终状态和结果。这样浏览器刷新、连接超时或断开，不必意味着整次任务丢失。

SSE 只负责把事件送给前端，不负责持久执行、重试或恰好执行一次。下单这类资金相关动作还要有稳定业务操作标识、权限与业务校验，以及订单状态确认；连接重连不能触发重复下单。

一条可落地的链路

1. 提交回测参数，完成校验后写入任务记录，返回任务 ID 与状态查询地址。需要时用 202 Accepted 表达已接收但尚未完成。
2. 可靠地将任务交给工作进程，记录待执行、运行中、成功、失败或取消状态；任务记录与投递之间采用可靠消息等一致性方案。
3. 前端订阅这个任务的 SSE 事件，展示阶段、当前进度和错误；连接失败后仍能通过查询接口知道任务状态。
4. 结果落到持久存储，完成事件携带结果引用；取消通过独立命令提出，由工作进程按安全检查点处理。

为什么不一直等待同步响应

同步长请求实现简单，短任务可以使用；但执行时间不可预测时，代理总时长限制、连接中断和响应丢失会使客户端无法判断业务是否已成功。持久任务将“工作有没有完成”与“这条连接是否还活着”分开。

异步也增加队列、任务恢复和状态管理成本。若任务很短、结果无需恢复，不必为了使用 SSE 增加整套任务平台。回测可重算，而已发出的交易指令不能简单重跑，恢复策略应分别设计。

对应教程

参考资料