交完卷，页面停在“报告生成中”，转了半分钟还没动静——用户此刻最想知道的不是后台架构，而是“我这份到底成没成、还要等多久”。异步出报告在集中提交时几乎是必然选择：提交只管把答卷安全落库，计分和报告生成丢进队列由后台慢慢消化，这样峰值才顶得住。但队列一旦堆积，用户侧的等待就需要被认真交代，而不是一个永远转圈的图标。
真正该给用户的，是一台能看见的状态机。一份答卷从提交到出报告，至少要区分几个明确状态：已提交、排队中、生成中、已完成、失败可重试。页面不该只显示笼统的“处理中”，而应把当前处在哪一步说清楚——排队时告诉用户前面还有任务、报告会稍后自动生成；进入生成中就明确提示正在计算、通常很快；完成后直接给出查看入口。
橙星云在异步出报告时就把这几个状态直接反映到用户界面上，让等待的人清楚自己是在排队还是在生成，而不是对着一个不变的转圈图标干等。
这几个状态还要在前端能自然流转，而不是靠用户不停手动刷新去碰运气。常见做法是页面轮询任务状态，或由后台在状态变化时推送，让排队变生成、生成变完成的那一刻，界面能及时跟上。用户看到的是一条在走的进度，而不是一个静止的圈。
队列堆积时，最忌讳两件事。一是假装很快：明明后面积压了大量任务，还显示“即将完成”，等超时了用户只会更慌。二是把失败藏起来：计分异常或报告模板出错导致这一份没生成，却仍旧停在“生成中”，用户永远等不到结果。堆积时更诚实的做法，是承认排队并给出一个大致范围，同时把“完成后通知你”这类兜底做扎实——即便用户关掉页面，报告好了也能通过站内或消息通知找回，不用守着页面干等。
失败这一态尤其要留出口。异步链路里任何一环出问题，状态都该明确落到“失败”，并且允许重试，而不是无声地卡住。对用户是一个清清楚楚的“重新生成”按钮，对系统是这份任务能被重新投递回队列。能重试，意味着一次偶发的堆积或异常不会让用户白填一遍。
异步出报告省下的是服务器的瞬时压力，但省下来的这部分，不能转嫁成用户的茫然等待。把排队、生成、完成、失败几个状态如实告诉用户，再配上完成通知和失败重试，队列堆得再高，用户侧的体验也是可控的。