@humbass #15  断点续传 和 断点下载是差不多的。一般的做法是 先建立一个 实际文件大小的 占位文件，还有一个 存储当前进度信息的 文本文件

预分配一个完整文件，用分块序号和分块大小计算要写入的偏移量，前端上传前先查询，后端返回未上传的分块序号。

@humbass #3  minio 是可以的，我们使用过，部署在内网的。

4G 左右的文件计算 MD 需要 13+S ，这个耗时前后端都不可避免，需要验证文件的完整性是有必要的。

至于后端小文件合并成大文件，可以使用一个线程合并，也可以使用多个线程分部分合并，然后继续往上合并。
后端也可以使用文件内存映射直接写入文件中对应的 fragment ，不把收到的部分写入小文件。

具体要分析是哪个部分慢，例如是计算 MD5 32 慢，看看是否改成 MD5 16 也能够满足需求。

有轮子就直接用。
minio 是 golang 实现的，很容易部署，我是用的 docker ，直接下载一个单文件应该也可以。

正好前段时间遇到类似的需求，我们采用的是 tus + minio

放硬盘里，人肉过去传输，最快。

请使用支持 S3 的相关存储(公有云对象存储或者私有云 minio)，建议 op 好好重读下 http 的 RFC ，https://datatracker.ietf.org/doc/html/rfc7233#section-4.2 有标准的协议不用，你去造轮子 https://i.imgur.com/U3hKhrT.png

@MoHen9  你说的是多线程下载，和断点续传有什么关系？

@unknown404 这是下载, 不是上传.