大文件分片上传不能直接用http.FileServer，因其同步阻塞、无断点续传、易致协程卡死和内存暴涨；必须自定义处理逻辑，包括调大ParseMultipartForm内存阈值（如1GB）、按filename+chunkIndex识别分片、分片存临时文件、合并时用os.O_APPEND追加写入。
大文件分片上传为什么不能直接用 http.FileServer
因为 http.FileServer 是同步阻塞式读取，一上传几百 MB 就卡死协程，内存暴涨，还无法断点续传。GoLand 只是 IDE，真正起作用的是你写的 HTTP 处理逻辑——得自己控制分片接收、校验、合并时机。
核心不是“用什么工具”，而是“怎么设计分片协议”：前端必须按固定 chunkSize 切片，后端按 filename + chunkIndex + totalChunks 识别归属，否则并发上传多个文件时会混片。
multipart/form-data 解析分片时容易漏掉 ParseMultipartForm 的内存阈值
Go 默认只缓存 32MB 的 multipart 数据到内存，超了就报 http: multipart: Part.Read: http: request body too large。这不是前端错了，是你没调大阈值。
- 在 handler 开头加
r.ParseMultipartForm(1024 * 1024 * 1024)（设为 1GB） - 必须在读取任何
r.FormValue或r.MultipartReader之前调用 - 不建议设为
0，否则全部写临时文件，IO 拖慢吞吐
分片合并必须用 os.O_APPEND 而非覆盖写入
多个分片并发上传时，如果每个都用 os.Create 打开目标文件，后到的分片会清空前面写的内容。正确做法是每个分片单独保存为临时文件（如 upload_abc_001.bin），最后用顺序读+追加写合并。
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
合并示例关键逻辑：
dst, _ := os.OpenFile("final.zip", os.O_CREATE|os.O_WRONLY|os.O_APPEND, 0644)
defer dst.Close()
for i := 0; i < total; i++ {
src, _ := os.Open(fmt.Sprintf("upload_%s_%03d.bin", fileID, i))
io.Copy(dst, src) // 不要自己循环 Read/Write，io.Copy 内部已优化
src.Close()
}注意：io.Copy 比手动 Read+Write 快，且自动处理 buffer 大小；合并前务必校验每个分片的 Content-MD5 header 或额外字段，防止网络丢包导致静默损坏。
GoLand 调试大文件上传需关掉 Run → Edit Configurations → Environment → GOPROXY=direct
默认 GoLand 启动时可能带代理或模块缓存干扰，上传中途断连常表现为 broken pipe 或 i/o timeout。实际不是代码问题，是调试器注入的 HTTP client 被代理劫持了连接。
- 在 Run Configuration 的 Environment variables 里显式加
GOPROXY=direct - 同时勾选
Allow running in parallel，否则多个分片请求会串行排队 - 上传测试用
curl -F "file=@large.zip" -F "chunkIndex=0" ...，别依赖浏览器，它会自动加 Referer/Cookie 干扰分片幂等性
真正难的不是写完代码，是让每个分片在 Nginx（如果有）、Go HTTP server、磁盘 IO 三层之间都不丢字节——尤其要注意 Nginx 默认 client_max_body_size 1m，这个必须改，而且要改在 http、server、location 三个层级里才生效。
