一个“虚线框 + 云朵图标”并不能解决文件上传。用户真正需要知道：为什么要上传、接受什么格式、多大、是否成功、出错怎么改、能不能重试、已上传文件是否安全。本文拆解完整上传状态和无障碍要求。
文件上传看起来是一个很小的组件，却经常成为开户、认证、招聘、报销、合同和数据导入流程中最容易失败的一步。用户可能拿着手机照片、加密 PDF、几十 MB 的视频、错误模板 Excel，甚至根本不知道“扫描件”是什么意思。只画一个漂亮 Dropzone，很难解决这些真实问题。
01 一、先问：真的必须让用户上传吗？
GOV.UK 当前 File Upload 指南给出的第一条原则非常直接：只有当文件对服务交付是关键时才要求上传。文件上传意味着设备权限、格式、网络、隐私和无障碍成本。如果可以直接填写数据、连接已有账户或复用此前材料，就不要强迫用户重新找文件。
02 二、在选择文件之前就把要求说清楚
不要等用户上传后才提示“仅支持 PDF，最大 5MB”。在控件旁明确写出接受格式、单文件大小、数量、是否必须使用模板、是否支持照片，以及敏感信息处理方式。W3C 的 Forms Tutorial 同样强调表单需要清晰 Label 和 Instructions。
03 三、保留“选择文件”，拖拽只能是增强
拖拽适合桌面用户，但不是所有人都能方便拖拽。GOV.UK 改进版组件同时提供 Choose file 和 Drag & Drop，并专门改善了语音识别与辅助技术体验。产品不要把整个交互只做成一个自定义拖拽区域，底层仍应有可访问的文件输入机制。
04 四、选中文件后立即反馈“你选了什么”
至少显示文件名、类型/大小、当前状态和删除/更换操作。多文件场景最好逐项展示，而不是只写“已选择 6 个文件”。如果系统会压缩、解析或病毒扫描，要把这些阶段区分开，避免用户看到 100% 以后仍然不知道为什么不能提交。
05 五、上传状态应该是一套完整状态机
- Idle：尚未选择。
- Selected：已选择但未开始或等待确认。
- Uploading：正在传输，显示可理解的进度。
- Processing：服务器解析、转码、扫描等后台处理。
- Success：明确告诉用户上传成功。
- Error：说明具体问题并提供重试或替换。
- Cancelled / Removed：用户主动取消或删除。
“Loading”一个状态无法覆盖这些差异。尤其大文件上传，传输完成和服务器处理完成是两个完全不同的阶段。
06 六、错误信息必须告诉用户怎么修
GOV.UK 对文件上传错误给出了非常具体的文案模式，例如文件类型不正确、文件过大、文件为空、包含病毒、密码保护、无法上传、超过数量限制、未使用指定模板。比“Upload failed”有效得多。错误信息应包含“哪个文件 + 什么问题 + 下一步怎么做”。
07 七、大文件和弱网络需要恢复能力
企业用户可能上传几十 MB 的合同、视频或数据包。网络中断后如果只能从 0% 重来，体验会非常差。根据业务和技术成本，可以支持暂停/继续、分片、断点续传、自动重试，至少也要保留已选文件和清晰的重试操作。
08 八、多文件上传要解决队列，而不只是 multiple=true
用户需要知道总数量限制、单个文件状态、整体进度和哪些失败。允许单独重试失败文件，而不是因为 1 个文件出错让 20 个全部重新上传。文件排序如果影响业务含义，也需要提供键盘可操作的替代方式，而不能只支持拖动。
09 九、让用户复用已经上传的文件
GOV.UK 明确建议在同一流程中尽量允许复用之前上传的文件，除非存在重要安全或隐私风险。比如用户已经上传身份证用于身份验证，后续地址证明如果业务允许，可以提供“使用已上传文件”而不是要求重新选择。
10 十、无障碍不只是给 Dropzone 加 aria-label
文件选择按钮需要清晰 Label 和说明；错误要与控件关联；键盘用户必须能完成选择、删除和重试；拖拽进入/离开状态应向辅助技术提供可感知反馈。GOV.UK 的改进版组件甚至为进入和离开 Drop Zone 提供可被辅助技术播报的状态文本，这说明高级上传体验不能只围绕鼠标设计。
11 十一、安全和隐私反馈要让用户看得懂
如果系统会扫描病毒、加密存储或限制文件保留时间，可以在相关场景明确说明，但不要用“银行级加密”这类无法验证的营销词。对于包含身份证、合同、医疗资料等敏感文件的流程，用户尤其需要知道用途、谁能访问、何时删除。
12 十二、移动端上传要考虑拍照和相册流程
很多身份证、票据和现场证明来自手机摄像头。移动端可以利用系统拍照/相册能力，但要提前说明是否需要正反面、是否接受截图、图片是否会被自动压缩，以及模糊、反光、裁切不完整时如何重拍。不要在文件上传后才告诉用户“照片不合格”，如果可以，应在本地或服务端尽早给出质量反馈。
13 十三、附件上传和数据导入是两类产品
合同 PDF 上传的目标是“把文件保存下来”，CSV/Excel 导入的目标则是“把数据正确写进系统”。后者除了传输状态，还需要字段映射、模板版本、解析结果、错误行定位、重复数据策略和回滚能力。不要用同一个通用 FileUpload 体验覆盖两者所有业务。
14 十四、上传完成后还需要“可确认性”
Success 不只是变成一个绿色勾。用户可能需要预览缩略图、查看文件名、下载确认、替换或删除。对于数据导入，还要继续显示解析结果：读取了多少行、哪些失败、是否可以下载错误报告。上传只是把文件传到服务器，用户任务通常还没有结束。
文件上传体验成熟的标志，是用户从选择前到上传后始终知道“系统现在在做什么、我下一步能做什么”。拖拽动画只是最表面的部分。
常见问题
文件上传一定要支持拖拽吗？
不一定。拖拽是桌面端的增强方式，必须同时提供标准的文件选择路径，移动端尤其依赖系统文件/相册选择。
上传前还是上传后校验文件格式？
可以在客户端先做快速校验提高反馈速度，但安全和最终有效性仍需服务器端验证，不能只依赖前端。
上传进度到 100% 是否代表完成？
不一定。100% 可能只表示传输完成，服务器还可能在解析、转码或安全扫描。界面应区分 Uploading 和 Processing。
多文件中一个失败，其他文件要重新上传吗？
通常不应该。最好保留成功项，并允许针对失败文件单独重试或替换。
文件上传组件最重要的文案是什么？
选择前的要求说明和失败后的具体错误通常最关键：用户必须提前知道接受什么，并在失败时知道如何修复。
相关服务与进一步咨询
链接复制成功
