go http上传中断时request.body会提前关闭并报io.errunexpectedeof，需流式读取、分片上传、哈希校验、临时文件清理及超时控制，标准库不支持断点续传。
上传中断时 http.Request.Body 会提前关闭，不重试就直接报错
Go 的 http.Server 默认把整个请求体读进内存或临时文件再交给 handler，但大文件上传中途断开（比如用户关浏览器、网络闪断），Request.Body.Read 会返回 io.ErrUnexpectedEOF 或 net/http: request body closed prematurely。这不是你代码写错了，是底层连接断了，而 Go 不会自动重试或缓冲恢复。
实操建议：
立即学习“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 协议原生能力，得靠业务层约定协议。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 客户端按固定大小（如 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 还是报。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 在
http.Server初始化时设MaxHeaderBytes和ReadTimeout（比如 30s），避免慢速攻击拖垮连接池 - 对上传接口单独加更短的
context.WithTimeout，比如 5 分钟，超时主动 cancelrequest.Context() - 用
http.TimeoutHandler包一层 handler，比在 handler 里手写 timer 更可靠 - 别用
MaxBytesReader替代分片逻辑——它防不了中断，也防不了恶意客户端发 1GB 垃圾数据再断连
客户端没发完就断，服务端残留的临时分片文件得定期清理
分片上传过程中用户关页面、刷新、或网络抖动，会导致部分分片写了一半或全写完但没发 finish 请求。这些文件不会自动删，占磁盘还可能被误合并。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 所有临时分片路径加时间戳前缀，比如
/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 标准库替你记。
