Golang大文件上传中断处理技巧

本文深入剖析了Go语言在处理大文件上传时遭遇网络中断的核心痛点——标准库无法自动恢复断开的连接，导致Request.Body提前关闭并抛出io.ErrUnexpectedEOF等错误；文章系统性地给出了生产级解决方案：摒弃ParseMultipartForm，采用流式分片读取与自定义断点感知机制，严格实施哈希校验与临时文件生命周期管理，结合超时控制、状态显式维护及后台清理策略，最终构建出高可靠、可续传、防攻击且易运维的大文件上传服务。

上传中断时 http.Request.Body 会提前关闭，不重试就直接报错

Go 的 http.Server 默认把整个请求体读进内存或临时文件再交给 handler，但大文件上传中途断开（比如用户关浏览器、网络闪断），Request.Body.Read 会返回 io.ErrUnexpectedEOF 或 net/http: request body closed prematurely。这不是你代码写错了，是底层连接断了，而 Go 不会自动重试或缓冲恢复。

实操建议：

• 别依赖 ParseMultipartForm 处理大文件——它默认只缓存 32MB，超限就写临时文件，但中断后临时文件可能残留且无法续传
• 用 request.Body 流式读取，配合 io.LimitReader 或自定义 reader 做断点感知（比如按固定块大小读，每块写完校验 checksum）
• 在 handler 开头加 defer r.Body.Close()，但必须先判断 r.Body == nil 或是否已被关闭，否则 panic
• 捕获 io.ErrUnexpectedEOF 和 net.ErrClosed，返回 408 Request Timeout 或 499 Client Closed Request（Nginx 常用），别返回 500

分片上传必须自己实现服务端校验逻辑，multipart.FormFile 不支持断点续传

Go 标准库的 multipart.Reader 和 FormFile 是为单次完整上传设计的，它解析 boundary、提取字段、解码 base64（如果用了）、一次性读完每个 part。一旦某一片失败，整个 ParseMultipartForm 就卡住或报错，没法“跳过已传部分”。分片上传不是 HTTP 协议原生能力，得靠业务层约定协议。

实操建议：

• 客户端按固定大小（如 5MB）切片，每片带唯一 upload_id、chunk_index、total_chunks、md5（或 sha256）作为 query 或 header 传过来
• 服务端收到后先检查 upload_id 对应的分片目录是否存在，再校验 chunk_index 是否已存在且大小/哈希匹配，避免重复写入
• 不要用内存存分片——用 os.CreateTemp 写磁盘，路径按 upload_id/chunk_index 组织，上传完成后再 io.Copy 合并
• 合并前务必逐片验证哈希，别信 Content-Length，中间代理可能篡改

http.MaxBytesReader 能防爆内存，但对上传中断没用

很多人以为设了 http.MaxBytesReader 就能兜住中断问题，其实它只限制单个请求体最大字节数，超限返回 413 Payload Too Large；但它不处理“读到一半连接断了”这种场景，该报 io.ErrUnexpectedEOF 还是报。

实操建议：

• 在 http.Server 初始化时设 MaxHeaderBytes 和 ReadTimeout（比如 30s），避免慢速攻击拖垮连接池
• 对上传接口单独加更短的 context.WithTimeout，比如 5 分钟，超时主动 cancel request.Context()
• 用 http.TimeoutHandler 包一层 handler，比在 handler 里手写 timer 更可靠
• 别用 MaxBytesReader 替代分片逻辑——它防不了中断，也防不了恶意客户端发 1GB 垃圾数据再断连

客户端没发完就断，服务端残留的临时分片文件得定期清理

分片上传过程中用户关页面、刷新、或网络抖动，会导致部分分片写了一半或全写完但没发 finish 请求。这些文件不会自动删，占磁盘还可能被误合并。

实操建议：

• 所有临时分片路径加时间戳前缀，比如 /tmp/uploads/20240520_upload_abc123_chunk_001，上传成功后 mv 到正式目录并删前缀
• 写个后台 goroutine 每小时扫一次 /tmp/uploads/ 下 2 小时前创建且无对应 finish 标记的文件，直接 os.RemoveAll
• 别依赖 defer 清理——handler panic 或 context cancel 都可能跳过 defer
• 如果用对象存储（如 S3），优先用它的 multipart upload API（CreateMultipartUpload + UploadPart + CompleteMultipartUpload），服务端状态由它维护，不用自己管清理

真正难的不是怎么读完一个文件，是怎么知道“现在读到哪了”“上次断在哪了”“用户是不是真想重试而不是换了个文件”。这些状态必须显式设计，不能指望 HTTP 或 Go 标准库替你记。

本篇关于《Golang大文件上传中断处理技巧》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于Golang的相关知识，请关注golang学习网公众号！