应基于文件哈希值实现上传前校验与服务端状态兜底：前端选文件后立即计算SHA-256并查询存在性，服务端按哈希锁定上传、拒绝重复分片，辅以Redis限流防并发。
防止用户重复提交相同的大文件，关键不在“禁用按钮”这种表面操作，而在于从文件内容本身建立唯一标识，并在上传前就做存在性判断。真正有效的方案，是把“秒传逻辑”前置到用户点击上传的那一刻。
用文件哈希值做上传前校验
这是最可靠、最通用的方法。浏览器端在选择文件后立即计算其 SHA-256（或 MD5）值，然后向服务端发起一次轻量查询：“这个哈希值对应的文件是否存在？”
- 服务端查到已存在 → 前端直接显示“秒传成功”，跳过所有上传流程
- 服务端未查到 → 正常进入分片上传流程，同时把该哈希值作为本次上传的全局标识
- 即使文件名不同、路径不同、修改时间不同，只要内容一致，就能识别为重复
上传过程中锁定操作入口
哈希校验需要时间，网络延迟可能导致用户误以为没响应而反复点击。此时需配合前端状态控制：
- 用户选择文件后，立即禁用上传按钮，并显示“正在校验…”
- 校验完成（无论是否存在），再根据结果启用按钮或自动触发上传
- 上传开始后，按钮保持禁用，直到 done 或 error 回调执行完毕
- 避免只靠
disabled属性，还要监听 click 事件并 return false，防绕过
服务端记录上传状态并拒绝重复请求
客户端控制可能被绕过，服务端必须有兜底机制：
- 每个上传请求都携带文件哈希值和分片序号
- 服务端收到分片时，先查该哈希值是否已标记为“上传完成” → 直接返回成功
- 若未完成，再检查当前分片是否已存在 → 存在则忽略，不存在则接收并落盘
- 合并完成后，将该哈希值写入“已完成文件表”，后续所有同哈希请求均短路处理
限制单个文件的并发上传请求
用户快速连点或脚本误操作，可能在极短时间内发出多个相同哈希的上传请求。可在网关或服务端加一层轻量限流：
- 以文件哈希值为 key，设置 60 秒内最多允许 1 次上传初始化请求
- 对分片请求不做严格限流，但要求必须带合法的上传 ID（由初始化接口返回）
- 使用 Redis 的
SETNX+ 过期时间实现，开销极低
