I3.07.1queryable background progress设计
后台任务需要可查询的进度
别名: 后台进度 · 查得到的进度 · job progress · 导出进度
概念解释
任务已经不占当前屏幕，人却必须能在想起来的时候问「现在到哪了」。可查询的进度（queryable progress）是一份不依赖「还盯着那块区域」的答案：百分比、阶段名、已处理条数，从固定入口能读到。转圈、一次性 toast、「请稍候」在人切走之后都不是进度——它们不能被再问一次。
这条要的是查询能力。完成时怎么喊人、要不要一张任务列表当组件，以及退出后是否续跑，是别的问题。没有可查询，后台等于把任务扔进了无法寻址的洞。
机制
超过大约十秒，注意会离开这条人机对话，任务却还在跑。离开之后，原位点上的像素变化不再进入知觉。进度若只存在于那块即将被离开的区域，信息与注意同时消失。可查询把进度做成可寻址状态：有一个名字、一个入口、一份当前值，人从别的屏幕、别的时间点仍能取样。取样是主动的，所以它不替代完成通知；它替代的是「我怀疑它卡死了只能干等」的那类焦虑。
进度还要在查询时是真的。一个永远 73%、或每次打开都从 0 跳到 90 的条，查询会变成第二次谎言。可查询包含稳定的当前值，不是「有一根条」。阶段名（「正在压缩」「正在上传」）在无法估计剩余时比假百分比更可问。
边界
一两秒内结束的动作不需要可查询进度，查询入口会比任务活得更久。完全不可中断、不可观察的内核工作（某些硬件擦除）只能报告「在进行」，但「在进行」仍须能被再问到，而不是只有第一次点击时的一句。多人共享的导出，进度应对发起人可查，不一定对所有协作者可查。屏幕阅读器用户的查询是读状态区或标题，而不是看条的宽度；可查询要对他们也成立。前端轮询被系统挂起时，进度在设备上会冻住，但任务可能在服务器上继续——查询应打到权威侧，而不是读一块过期的本地条。
怎么落地
- 每个可能超过十秒的后台工作都有一个可再次打开的进度视图：阶段或比例，加上开始以来的已用时间。
- 进度入口在任务存活期内一直在，不随当前页卸载。离开再回来，值接上，不从零演一遍。
- 不能估计剩余时展示阶段与已完成量，不编造百分比。
- 验证：发起一次至少 30 秒的导出，切到别的页面，再从入口问进度。若入口不存在、或打开后是空白/从 0 开始演，失败。把网络调慢让阶段停在「上传」：查询到的阶段应仍是上传，而不是一根假的平滑条。