文件上传交互要让用户看懂三件事：哪些文件可以选，每个文件现在到了哪一步，失败后怎样继续。多文件上传尤其要保留逐项结果；不能因为一张附件失败，就清空其他已经成功的文件，也不能把“进度100%”直接写成“业务处理完成”。
以报销单附件为例，用户选中了三张发票，真正关心的是哪些已附到报销单、哪些需要重选，以及现在能否提交。上传按钮只是入口，附件列表、进度、错误说明和提交条件才共同组成完整体验。评审前，可以用墨刀原型演示上传与重试流程，让团队逐项确认状态和提交条件。
选择文件之前，把限制写在入口旁
“请选择文件”给的信息太少。用户至少应在操作前知道支持的格式、单个文件大小、数量上限，以及是否允许重复添加。限制来自实际业务与技术约束，不应从别的产品随手复制。
下面采用一组教学规则：一张报销单最多添加5个PDF、JPG或PNG附件，每个不超过10MB；选择后立即上传，成功附件先保留在报销草稿中，提交报销仍是单独动作。这些数字用于说明设计方法，不是通用标准。
| 位置 | 示例文字 | 需要解决的问题 |
|---|---|---|
| 上传区标题 | 报销附件 | 说明上传对象 |
| 操作入口 | 选择文件，或拖放到此处 | 拖放之外保留点击方式 |
| 辅助说明 | 支持PDF、JPG、PNG；单个不超过10MB，最多5个 | 在选择前提供限制 |
| 数量提示 | 已添加3个，还可添加2个 | 成功项与待处理项是否占名额要一致 |
如果系统还能接受多个同名文件，就不能只凭文件名判断重复。界面可以提示“已存在同名附件，请确认是否仍要添加”，而内容是否相同、是否覆盖旧文件，应由业务与实现共同确定。重复选择不应悄悄替换已提交的附件。
IBM的Carbon文件上传指南也把格式、大小说明以及单文件错误反馈放在上传组件附近。这里值得借鉴的是信息与操作的关系，不必照搬其尺寸和视觉样式。
进度到100%，不一定已经可以使用
文件可能还要经过格式检查、解析或其他业务处理。用户等待的终点是附件可用，因此界面应说明当前进度代表哪一段。如果只能拿到传输进度，就在完成后切换为“上传完成，正在检查”，不要让一个100%的进度条一直停在那里。
无法获得可靠百分比时，可以显示“正在上传”及已处理数量。不要让动画匀速跑到99%来制造确定感，也不要在没有可靠依据时承诺“还剩3秒”。
| 单文件状态 | 用户看到什么 | 可以做什么 |
|---|---|---|
| 等待上传 | 文件名、大小、等待中 | 从队列移除 |
| 上传中 | 正在上传；有可靠数据时显示进度 | 按既定能力取消 |
| 传输完成，处理中 | 上传完成，正在检查 | 等待；是否可取消另行约定 |
| 可用 | 已添加到报销草稿 | 查看或移除附件 |
| 上传失败 | 说明失败原因及文件是否保留 | 重试或重新选择 |
| 检查未通过 | 说明文件为什么不能使用 | 更换符合要求的文件 |
上传期间允许继续填写报销信息通常更顺畅，但提交按钮的条件必须清楚。对于本例，只要仍有上传中、检查中或未处理失败项，提交前就需要提示用户处理附件。也可以设计允许忽略失败附件后提交，但必须由用户明确选择，不能静默丢掉他准备报销的材料。
部分失败时，保住已经成功的附件
假设用户选择了“交通发票.pdf”“住宿发票.png”“餐饮发票.exe”。前两项符合本例规则，第三项不支持。附件列表应保留三项的对应结果；错误消息紧贴餐饮文件，告诉用户改成支持的格式，而不是用一个全局“上传失败”掩盖实际情况。
列表顶部可以汇总为“2个附件已添加，1个需要处理”。“仅重试失败项”适合网络异常等可重试原因；格式不支持则应提供“重新选择”或“移除”，反复重试同一个文件不能解决问题。
如果用户同时选了6个文件，而本例只允许5个，应在上传开始前说明处理规则。例如保留前5项并明确指出第6项未添加，或要求用户重新选择。不要让列表显示6项，却只在提交时突然告诉他有一个无效。何时计算数量，也要与失败项、取消项及已有附件保持一致。
取消、重试和移除，是三个不同动作
取消上传针对正在进行的任务，重试针对失败任务，移除附件针对已保留的结果。即使视觉上都能用一个小图标，也应提供明确名称，让用户知道这次操作影响什么。
- 取消一项时，其他文件继续上传；如果操作的是整批队列，按钮应写“取消全部上传”。
- 取消请求与完成响应可能同时到达。若服务端已经接收成功，界面应依据最终结果显示，不可一直停在“已取消”却实际附上文件。
- 重试后沿用同一条文件记录或清楚合并结果，避免一次失败重试产生两份附件。
- 移除成功附件后，草稿中的附件数量立即与列表一致。是否同时删除服务端临时文件，是研发需要实现和确认的规则。
当网络超时、是否接收成功尚不清楚时，可显示“上传结果待确认”，先查询同一任务。直接把未知结果当失败并发起新上传，可能造成重复附件。恢复路径可以参考后台异常状态设计，但提示仍要写出当前文件的具体状态。
离开页面后，上传还能继续吗
这取决于真实实现。设计稿不能因为任务条可以最小化，就宣称上传会在后台继续。如果当前方案离开即中断，应在跳转前说明哪些仍在上传、已经完成的附件能否保留，并提供“继续等待”和“离开并中止”等符合实际结果的选择。
如果允许离开后继续，用户需要在报销草稿或任务列表里找回进度。返回时加载已有任务状态，不要把所有附件重新上传一遍。手机切换应用、断网后恢复、刷新页面的行为也应分别与研发确认，不能用一条“支持后台上传”笼统带过。
用同一批文件走通上传原型
可以在墨刀原型中从一张报销草稿页开始：搭建上传区与附件列表，再复制出上传中、部分失败和全部可用的页面，用交互连线连接选择、重试、移除与返回。演示中的进度和文件结果属于预设状态，不代表已经接入真实上传服务。
- 把本例的格式、大小、数量和提交条件写在页面旁，团队先确认这些规则。
- 建立三条固定文件记录，所有状态页沿用相同文件名，避免列表与提示对不上。
- 为“不支持的格式”和“网络失败”各建一条分支，前者更换文件，后者重试原项。
- 成功分支返回同一张报销草稿；移除一项后，列表与数量同步变化。
- 补上传未结束时离开页面的分支，并注明它依赖哪一种实际实现。
评审时分别试一次：选6个文件、上传中取消其中一项、两项成功后一项失败、重试时再次点击、处理未完成就提交，以及中途离开再返回。如果任何路径只能靠讲解才知道文件去了哪里，就继续补对应的列表状态或文字说明。上传体验是否清楚，最终要看用户能否找到自己的每个文件并完成后续提交。
延伸阅读：需要把附件放进完整业务表单时，可参考表单字段、校验与提交状态的设计方法。官方规范参考：Carbon File uploader。
