17370845950

Go文件分片上传需确保分片不丢、顺序不错、断点可续、并发可控：客户端分块读取并并发上传，服务端存临时分片后合并校验，双方通过状态管理实现断点续传，并加入指纹校验、超时重试等增强机制。

用 Go 实现文件分片上传，核心是把大文件切分成小块（chunk），逐个上传，再在服务端合并。关键点不在“能不能传”，而在于如何保证分片不丢、顺序不错、断点可续、并发可控。

一、客户端：按块读取 + 并发上传

不要一次性把整个文件读进内存。用 os.Open 打开文件，配合 io.ReadAt 或分段 bufio.Reader 按偏移量读取每一片（如 2MB/片）。每片生成唯一标识（如文件名+md5+序号），带上当前 offset 和 totalSize，通过 HTTP POST 发送到后端。

• 用 sync.WaitGroup 控制并发数（比如最多 3 片同时上传）
• 每片上传前检查本地缓存的上传记录（如 JSON 文件），跳过已成功上传的片
• 上传失败时记录失败 offset，下次从该位置继续，不重传已成功的片

二、服务端：接收分片 + 合并校验

接收接口不做业务逻辑，只存分片到临时目录（如 /tmp/upload/{file_id}/chunk_001），返回成功即写入磁盘。所有分片上传完成后，客户端触发合并请求。

• 每个分片保存为独立文件，命名含序号，便于排序
• 合并时按序号从小到大读取所有 chunk，用 io.MultiWriter 写入最终文件
• 合并后计算最终文件 md5，和客户端传来的原始文件 hash 对比，不一致则返回错误

三、断点续传：靠唯一 ID + 分片状态管理

关键不是“记住了没”，而是“怎么快速知道缺哪几片”。客户端和服务端都要维护一份轻量状态：

• 客户端本地存一个 upload_state.json，含 file_id、total_chunks、uploaded_offsets、upload_time
• 服务端用内存 map 或 Redis 存 {file_id → map[int]bool} 表示哪些片已收到
• 客户端发起上传前先 GET /api/v1/upload/status?file_id=xxx，拿到已上传列表，只传缺失的片

四、实用增强点（非必须但很稳）

上线前建议加这几项，能少踩 80% 的坑：

• 分片指纹校验：每个分片上传时附带自身 md5，服务端收到后立刻校验，防止网络损坏
• 超时与重试：单片上传设置 30s 超时，失败自动重试 2 次，超过则中断并提示用户
• 清理机制：未完成的分片超过 24 小时自动删除，避免磁盘被占满
• 进度回调：上传时通过 channel 推送当前完成百分比，方便前端显示进度条

基本上就这些。不复杂但容易忽略细节——比如没校验分片完整性，最后合并出一个打不开的文件；或者没控制并发，把服务端连接池打爆。边写边测几个大文件（500MB+），问题基本就浮出来了。