文件上传失败怎么设计？重试、恢复与重复文件的交互规范

上传失败后，用户最关心的通常不是错误码，而是三个问题：文件还在不在，刚才的进度还算不算，下一步该点哪里。一个能正常选择文件的上传框，只完成了流程的开头；网络中断、多文件部分成功和重复提交，才决定用户能否把任务做完。

以采购系统提交合同为例，用户同时添加合同、发票和补充说明。合同已经成功，发票在传输时断网，补充说明格式不支持。如果整个区域只显示“上传失败，请重试”，用户很可能把三份文件全部重新提交。设计应把任务拆到每个文件，同时保留整个队列的完成情况。上传嵌入表单时，可先对齐B端表单的字段与反馈结构，再补齐下面的恢复规则。

先区分：没有上传成功，还是上传后处理失败

“上传”在界面上像一个动作，在系统中可能经历选择、检查、排队、传输、扫描或解析、保存多个阶段。进度条到100%可能只说明文件传输结束，并不代表合同已经能预览、识别或被业务单据引用。若后续还要等待，界面应切换为“正在处理”，并在真正完成后显示可查看或可提交的结果。

Carbon文件上传组件规范要求在选择前说明限制，并为文件提供上传状态。实际业务可以在此基础上细分失败原因，但不必把所有后端步骤照搬给用户：只保留那些会改变等待方式、可用操作或恢复路径的状态。

错误文案不要一律归因于文件。服务临时不可用时写“暂时无法完成上传，请稍后重试”，比“文件有误”更准确。只有系统确实识别到大小、格式或内容问题，才要求用户修改文件。界面也不需要暴露内部存储路径、鉴权参数或原始异常堆栈。

以单个文件为单位组织队列

每个文件行至少保留文件名、可辨认的类型或大小、当前状态和下一步动作。长文件名应能查看完整名称，不能把区分版本的后缀全部截掉。合同_v3和合同_v4若在窄屏里显示成相同的“合同…”，用户很难决定删除哪一个。

队列顶部展示“3个文件，1个完成，2个需要处理”，文件行分别解释原因。错误只影响出错项，成功项保持稳定。多个文件处于相同的可恢复错误时，可以增加“重试失败文件”；含有格式不支持的文件时，不要让这个按钮看起来可以解决全部问题。

用户删除一个排队项，应只把它从本次任务移除；取消一个正在上传的文件，还要明确服务端已接收的临时数据如何处理。业务上已经保存并引用的附件，通常属于另一种删除操作，需要另外的权限和后果提示，不能与“取消上传”共用一个含糊的叉号。

重试和继续上传必须承诺不同的事情

“重试”可以从头发送文件，“继续上传”则容易让人理解为保留已完成进度。设计稿采用哪个文案，必须与工程实现一致。只有服务端支持恢复上传会话、已接收分片仍有效且本地文件可用时，才承诺从中断处继续。不能因为进度条停在60%，就默认剩余只需传40%。

以100 MB的文件为例，如果实现只支持完整重传，重试后进度归零是合理的，但应明确显示新的上传过程。若支持续传，可以保留“已传60 MB”的信息，并在恢复前校验文件与会话仍匹配。刷新浏览器、重新打开页面后是否还能恢复，是另外一项能力，不能用“页面内可重试”替代验收。

还要考虑用户点击重试时，前一次请求其实已经成功，只是客户端没有收到回执。产品和开发应共同约定任务标识与去重策略，让相同任务的重发不会生成两个业务附件。设计侧需要画出“正在确认上传结果”的过渡状态，而不是马上再创建一个同名文件行。

进度要解释等待，不要制造虚假的完成感

能得到可信的传输进度时，显示已传大小或百分比；无法估算处理耗时时，使用处理中状态并说明当前动作。不要把后半段伪装成固定百分比爬升，也不要在传输达到100%时提前显示“上传成功”。关于确定进度和不确定进度的使用边界，可参考Carbon进度条规范。

大队列还需要决定整体进度的口径：按文件数计数，还是按总字节计算。一个1 MB文件和一个1 GB文件各算50%，容易让总体进度误导用户。若显示“已完成2/5个文件”，就坚持用文件数表达，不要同时把它包装成精确的剩余时间。不同等待场景也可结合加载反馈的选择方法处理。

重复文件、离开页面和表单提交怎么处理

同名不一定是同一个文件，同一个文件也可能改过名字。若业务允许版本更新，遇到同名文件应询问替换、另存还是取消；若上传的是不能重复入账的凭证，去重依据应由业务规则和服务端识别结果确定。不要仅凭文件名相同就静默覆盖已有附件。

离开页面的保护也要分情况。未开始上传但已选择的本地文件，可能无法在重新进入后自动找回；正在传输的任务可能随页面关闭中断；服务端已经接收、进入后台处理的任务，则可能继续完成。弹窗应说明当前真实后果，例如“离开后将停止2个文件的上传”，不要泛用“所有内容将丢失”。

上传组件位于申请表内时，需要确定附件是否必填、哪些文件已正式关联到申请，以及还有文件处理时能否提交。合同必填且尚未完成，应在提交时指明阻塞原因；可选补充材料失败，不必让用户重新填写整个表单。服务端保存失败时，保留用户已输入的业务字段和已确认成功的附件。

让重试有终点，也让失败记录可追踪

网络恢复后是否自动重试，应提前确定。一次短暂断连可以按约定自动恢复；用户主动取消、文件不合规和权限被拒绝，则不应被自动重试循环覆盖。每次重试都要让同一个文件行继续更新，不能不断追加新的“正在上传”记录。等待时间较长时，把“重试中”与“等待连接恢复”区分开，避免用户以为按钮没有响应。

采购人员可能需要切换到别的任务，不应被要求一直盯着上传框。若系统支持后台任务，完成通知要能回到原申请及对应附件；若只支持当前页面内上传，就应清楚说明需要保留页面。给错误详情提供可复制的任务编号有助于定位问题，但编号应放在次要位置，主要文案仍回答当前文件怎样处理。日志记录的失败类型、重试次数、最终成功率可以用来找出恢复流程的薄弱点，不要仅统计用户点击过多少次重试按钮。

删除失败项后，焦点应落在剩余文件或添加文件入口等合理位置；重试成功后保留短暂且可感知的完成反馈，避免列表瞬间重排，让用户找不到刚刚处理的文件。排序确需变化时，保留结果摘要，再由用户选择收起已完成项。

交付前用六条路径验证恢复能力

动态状态不能只靠颜色改变传达。按照W3C状态消息说明，适当的完成、进度和错误反馈需要让辅助技术获知，同时避免为普通进度更新反复抢走焦点。上传按钮也应提供点击选择文件的路径，不能只有拖拽区域。其余视觉与操作要求可结合UI无障碍检查清单验收。

在设计稿中把恢复路径连起来

可以在Pixso中整理上传组件与交互稿：先用相同文件名制作待上传、传输中、处理中、成功、可重试失败和不可重试失败六个状态，再把三个文件组合为部分成功的队列。这样评审时讨论的是同一份合同如何恢复，而不是六张互不关联的漂亮页面。

原型中重点连接“失败→重试→处理中→完成”和“格式错误→更换文件→重新检查”两条路径；把刷新后恢复、去重和附件关联规则写在对应画板旁。参考高保真原型需要覆盖的状态，邀请产品、研发和测试从一次真实提交走到成功结果，缺失的反馈往往会在这一步暴露出来。