接口返回 202 就能亮完成灯吗，怎样跟踪异步任务回执

202 Accepted表示请求已被接受处理，处理还没有完成，之后也可能失败。完成灯应等待接口文档约定的任务终态与必要回读，不能收到202就直接亮起“完成”。如果接口没有任务查询地址或结果推送契约，应明确显示“已受理/结果待确认”，并向接口方补齐闭环。

环境和证据范围

HTTP只规定202语义，不规定job_id、status_url、running、succeeded这些业务字段。附件定义一套合成任务资源契约用于核对界面，路径不是真实设备API。没有调用播放器、中控或任何远程服务，也未验证产品是否原生支持这些字段。

核对顺序

1. 先约定受理响应包含哪些信息：可追踪任务标识、查询或订阅方式、可用期限以及最终状态集合。若只有一句OK但无关联信息，客户端无法可靠追到这次请求的结果。

2. 把界面状态分为发送中、已受理、运行中、成功、失败和结果未知。受理后保存任务标识；查询404、连接中断或字段缺失进入待确认分支，不自动等同于成功或重新创建任务。

3. 使用同一个任务的running→succeeded序列检查完成灯，再用running→failed检查错误详情。至少记录接口报告终态的时间和设备状态回读的时间，避免把队列完成与现场生效混为一谈。

4. 规定查询频率、最长等待与任务资源过期策略。示例不决定真实等待门限；超时后保留任务编号供人工追查，后续若收到迟到结果要结合当前界面任务版本处理。

可复算的输入与预期

附件四组输入分别为202带任务地址、运行中、成功终态和失败终态，预期“已受理”“运行中”“完成”“失败”；另一个202缺任务地址返回“受理但不可追踪”。脚本执行的是这套明示业务契约，不产生真实HTTP请求。

下载与现场记录

下载本题合成输入与预期JSON、离线只读核验脚本和现场空白记录CSV。放在同一目录，用 Python 3 运行 python verify.py，逐项计算或解析后与预期比较，失败会显示差异。

现场字段包括 request_id、http_status、task_url、task_state、terminal_at、device_readback、unknown_reason。合成样例保持原样，实测另存并填写型号、版本、证据路径，未采集处留空。本地核验不代表真实设备、代理、浏览器或长期稳定性已测。

失败分支与移交

HTTP查询返回200仍可能表示任务正在运行，必须解析业务状态。相反，任务失败也可能通过200响应中的failed字段表达，不能只把非2xx当失败。已受理后盲目重发可能创建新任务；是否允许重试应由接口契约另行规定，本页不提供去重实现。

移交应附受理样例、所有终态样例、错误结构、未知状态处理与任务编号的留存位置。真实验收还要安排设备拒绝、执行失败、结果查询丢失三条失败路径，并给运营说明“已受理”界面与“已完成”界面的区别及取证入口。

基础背景可看HTTP / RESTful 设备控制接口科普。异步受理之外，无内容成功响应也需单独处理，见接口返回 204 却报 JSON 解析错，怎样处理没有响应体。更多资料在设备协议库。

需要接入中控时，可对照SoftControl设备联动需求核实适配范围；独立校验方法是否纳入交付需逐项约定。

一级资料

• 官方资料：§15.3.3 202不表示处理已完成；任务字段是应用约定

核对日期：2026-10-24。规范定义与本文应用约定分开，示例门限及脚本不自动代表产品原生能力。