异步API轮询：为何需单独Get Status步骤？步骤2、3为何拆分？

很多人会疑惑，既然可以把状态查询和结果获取合并成一个接口——未就绪返回状态标识，就绪直接返回结果，为啥主流方案还是要拆成两个独立环节？核心原因集中在以下几点：

• 职责单一，语义明确
  拆分后，状态接口只专注于返回任务的执行状态（待处理/执行中/已完成/失败），结果接口只负责返回最终的业务数据。这种单一职责的设计让客户端和服务端的逻辑都更简洁：客户端轮询时只需要处理轻量的状态信息，服务端也不用在任务未完成时去预加载或准备结果相关资源。

• 性能与资源消耗优化
  任务未就绪时，状态接口的响应体极小（比如仅包含{"status": "pending", "progress": 30}），而结果接口可能返回KB甚至MB级的业务数据。如果合并接口，每次轮询都要执行结果是否就绪的判断逻辑，甚至可能提前占用内存加载部分结果，既浪费带宽，也增加服务端的计算压力。

• 错误场景隔离处理
  两个接口的错误类型完全不同：状态查询失败可能是任务ID无效、服务临时过载；结果获取失败可能是任务执行出错、数据持久化失败。拆分后可以分别定义针对性的错误码和处理逻辑，客户端能快速定位问题——比如轮询状态时返回404，就知道是任务ID错了；获取结果时返回500，就知道是任务执行出了问题。

• 扩展性更强
  后续迭代时，拆分的结构更容易扩展：比如给状态接口增加「预估完成时间」「执行日志片段」，或者给结果接口增加「数据格式选择」「分页参数」，两者的修改不会互相影响。如果是合并接口，调整任何一个逻辑都可能破坏另一个场景的兼容性。

• 缓存策略适配
  任务完成后的结果数据通常是静态的（不会再变化），可以直接缓存到CDN或者客户端本地，减少重复请求；而状态数据是动态变化的，不能缓存。拆分后可以分别配置缓存规则，进一步提升整体性能。

内容的提问来源于stack exchange，提问作者de1337ed