网站报表生成一直转圈？把耗时任务做成可查询、可核对的处理流程

客户点了“生成报表”，页面一直转圈；几分钟后超时，再点一次却生成两份。等待本身不一定能消除，但网站可以让客户知道请求有没有收到、现在处理到哪一步、离开后去哪里找结果。耗时功能的交付重点，是把一项业务的开始和结束连起来，而不是给等待动画加上百分比。

先确认这项工作是否确实需要异步处理。能在可接受时间内稳定完成的小任务，没有必要增加复杂流程；当处理经常超过正常页面等待范围，或者客户需要关闭页面后继续查结果，再设计独立的任务记录和查询入口。

先定义每个状态承诺了什么

“已接收”不是“保证成功”。HTTP 的 202 状态也只表示请求被接受处理，任务可能还没开始，后续仍可能失败。面向客户可以不展示这些技术名词，但开发验收要区分接收确认和最终结果，不能收到一次成功响应就把任务标为完成。

用一个完整例子，说明百分比到底在算什么

以下为虚构的文件转换任务：客户提交 120 份文档，要得到转换后的文件包和处理清单。任务依次经过检查输入、逐份转换、汇总打包和结果检查。转换到 90 份时，其中成功 87 份、失败 3 份、尚未处理 30 份。

此时 90÷120＝75% 表示“已处理文件比例”，成功比例是 87÷120＝72.5%，两者不能混写成“任务已成功 75%”。剩下的 30 份可能更大，最后还要打包，所以也不能据此保证剩余时间只有总时长的四分之一。

可显示“转换阶段：已处理 90/120，成功 87，失败 3；后续仍需打包检查”。等全部文件尝试完毕，若成功 116、失败 4，应显示部分完成，并提供明确失败原因或可采取的动作；不能只显示“100%”，让客户误以为 120 份全都可用。

不知道总量，或各步骤耗时差异很大时，使用阶段说明比伪造精确百分比更可靠。排队时也不要让进度条按秒自动前进。只能确认正在等待，就说明等待；预计时间应有实际依据，并在条件变化时更新。

刷新、关闭和再次进入，不应丢掉任务身份

任务被接收后，应能通过一个明确编号或记录找到它，而不是只存在于当前页面的动画里。客户刷新后再次查询同一任务，应该看到当前状态和最后更新时间；查询网络中断时，可显示上次状态并标注暂未更新，不能据此把后台任务判为失败。

状态入口和结果文件都要核对用户权限。任务编号用于定位，不是访问授权；猜到另一个编号不应看到别人的资料。退出登录、账号权限变化后如何处理，也需要有一致规则。

报表结果应注明输入条件和数据口径，例如选择了哪个日期范围、采用哪个时间点的数据。任务执行期间业务资料继续变化时，是固定快照还是执行时读取，需按实际方案说明；不能把早先生成的文件一直标成实时最新。

重试之前，先知道上一次到底做了什么

点击后没收到响应，可能是请求根本没有到达，也可能是任务已创建但确认丢失。此时重试应能识别同一次提交，返回已有任务，而不是再创建一个。仅禁用按钮无法覆盖刷新、断网重试和多个标签页；接收端也需要对应的重复请求处理。

回到虚构例子，4 份失败文件不应导致已经成功的 116 份无条件全部重做。可以在确认失败原因后，仅处理失败项，并记录新旧结果的关系；若修改了原始文件或转换要求，应把它作为新的输入版本处理，不能混在旧结果包里却没有说明。

对带实际业务副作用的批量操作，重试更要核对已完成范围。例如某条通知已经发出，再次执行不等于自动撤回旧通知。技术方案需要保证重复请求不会无意重复产生结果；不能把所有错误统一处理成“再试一次”。

取消和完成，也各有最后一步

“取消请求已收到”与“已经停止”应分开。任务可能正在处理某个不可立即中断的步骤，取消前已生成的结果也不一定能自动撤销。页面应说明正在停止、已经停止及保留下来的结果，不让客户误以为点击取消后所有动作都未发生。

完成时检查结果能否取得、文件是否可读、数量和明细是否一致。还要说明保留期限：结果过期后可以重新生成，还是需要联系客服，不能只留下一个失效下载按钮。生成完成但下载受权限或网络影响时，也应与任务执行失败区分。

验收沿着任务走一遍，而不是只测正常完成

用受控样例覆盖排队、部分失败、刷新查询、关闭后返回、确认丢失后的重试、取消和结果到期。逐项核对任务编号、输入范围、成功失败数量及最终文件；再用另一测试账号确认无法读取不属于自己的结果。

交付一份能对应页面状态与处理记录的验收结果。客户看见什么、哪些结果可以使用、下一步怎么做，都能由真实记录支撑，才算解决“页面一直转圈”的问题。

需要开发报表生成、文件转换或批量处理功能，可以私聊客服，说明输入规模、处理时间和失败后的业务要求，沟通进度、恢复与结果查询范围。

参考资料：MDN：202 Accepted；Microsoft：异步请求、状态与重复请求处理。