I3.07.2background completion notification设计
完成与失败都需要通知
别名: 后台通知 · 失败也要喊 · job done notify · 导出完成
概念解释
人已经不在看了，任务结束（做成或做砸）必须把人喊回来。完成与失败都要通知：成功不是「进度条悄悄到 100」，失败不是「入口里哪天变成了红色」。通知是主动通道——系统通知、应用内未读、邮件，取决于人当时在哪——目的是把注意从别的任务里拉回这一件。
只通知成功、失败靠人自己发现，失败会在沉默里变陈。只通知失败、成功靠人自己回头看，成功会在过期的等待里被误当成还在跑。两条都要发。
机制
十秒之后主注意已经切走。结束事件落在原位点上，等于落在空房间。通知换一条还活着的通道：操作系统的通知栏、锁屏、邮箱、桌面角标。通道的选择跟着「人现在的注意在哪」，不是跟着「任务对象在哪」。
失败通知的信息结构与成功不同。成功可以短：「导出好了」加打开。失败必须把下一步说出来，否则人被喊回来却站在一块无法行动的红字前面，第二次离开会把失败再埋掉。两端都静默时，模型停在「大概还在跑」。这个冻结的模型会阻止重试、也会阻止依赖结果的下一步，直到某次偶然打开。偶然不是机制。
边界
人还盯着进度视图时，视图上的终态就是通知，不必再弹一条系统通知抢焦点——但一旦视图不在前台，系统通知补上。免打扰、夜间、会议模式可以延迟展示，不能取消事件本身；延迟结束仍要送达。批量里九件成功一件失败，不能只发一条「已完成」把失败埋进列表。法律或安全不允许锁屏上显示内容时，通知可以是「有一项导出已结束，打开查看」，失败仍须可被打开后看见。用户明确关掉这一类通知，要在进度入口里把未读终态攒着，不能理解为「可以不告诉」。
怎么落地
- 任务进入终态的那一拍，向人当前不在的通道发一条：成功可打开结果，失败可看见原因入口。
- 成功与失败用不同文案和不同视觉权重，不要共用一个「任务更新」。
- 通知被点开应落到该任务的终态，而不是产品首页。
- 验证：开始一项后台工作，切到其他应用或锁屏。成功一次、失败一次。两次都应有主动通知；点失败通知应看到原因，而不是一根停住的条。关掉系统通知权限再跑一次：终态必须还在应用内可发现，不能随权限一起消失。