Gin大文件分片上传需设置router.MaxMultipartMemory（如1024<<20）以避免默认32MB限制导致400错误，该值控制multipart解析时内存上限，超限会直接拒绝请求。
大文件分片上传时如何避免 Gin 默认的内存限制
Gin 默认使用 gin.DefaultWriter 和 gin.DefaultErrorWriter，但更关键的是其底层依赖的 http.Server 并未限制单次请求体大小 —— 真正卡住你的是 gin.Engine.MaxMultipartMemory。这个值默认只有 32MB，一旦分片文件超过它，Gin 就会直接返回 400 Bad Request 并抛出 "http: request body too large" 错误。
必须在初始化引擎后立即设置：
router := gin.Default() router.MaxMultipartMemory = 1024 << 20 // 1GB，按需调整
- 该设置只影响
multipart/form-data解析阶段，不改变 Go 标准库的http.MaxHeaderBytes或 TLS 缓冲区限制 - 若用 Nginx 做前置代理，还需同步配置
client_max_body_size，否则请求根本到不了 Gin - 不要在 handler 中临时修改它 —— 这个字段是全局生效的启动期配置
分片上传中如何安全提取并校验分片元信息
前端通常通过 query 或 form 字段传递分片序号、总片数、文件唯一标识（如 file_id）和当前分片 hash。Gin 的 c.Request.FormValue() 或 c.DefaultQuery() 可读取，但要注意：
- query 参数易被篡改，敏感逻辑（如分片序号拼接）必须服务端校验，不能信任
chunk_number字段的连续性 - 推荐用
c.MultipartForm()一次性获取全部 form data，避免多次调用导致 body 被 consume - 务必对
file_id做白名单或签名验证，防止恶意用户伪造 ID 扰乱其他用户的合并队列 - 示例中常见错误：用
c.Param("chunk")从 URL path 提取序号 —— 这会导致路由冲突（如/upload/1和/upload/10都匹配/upload/:chunk）
分片写入磁盘时为什么不能直接用 c.FormFile() 保存
c.FormFile("file") 返回的是 *multipart.FileHeader，它内部调用 header.Open() 得到的 io.ReadCloser 是临时内存缓冲或临时文件句柄，**不是原始字节流**。直接 io.Copy() 到目标路径看似可行，但有隐患：
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
- 若分片来自内存（小文件），
FileHeader.Open()返回的是bytes.Reader，没问题；但若已落盘为临时文件，Gin 会在 handler 返回后自动清理os.TempDir()下的临时文件 —— 你刚Copy完，文件就被删了 - 正确做法是用
header.Open()获取 reader 后，立刻io.Copy到你可控的持久化路径，例如：/tmp/uploads/{file_id}/chunk_{n} - 务必检查
os.Stat()写入后的文件大小是否与header.Size一致，网络中断可能导致截断 - 别用
c.SaveUploadedFile()—— 它内部就是调用FormFile().Open()+Copy，同样受临时文件生命周期影响
合并分片时如何避免竞态和重复触发
当最后一个分片上传完成，服务端需触发合并。但多个分片请求可能并发到达，导致同一文件被多次合并。不能依赖“收到第 N 片就合并”，因为网络延迟可能让第 N-1 片晚于第 N 片到达。
- 推荐方案：用 Redis 或本地文件锁（如
flock）做合并互斥。例如，以merge_lock:{file_id}为 key，setnx + expire 控制合并入口 - 合并前先检查所有分片文件是否真实存在且大小匹配（对比
Content-Range或前端传的chunk_size） - 合并后立即计算最终文件的 SHA256，并与前端传的 total file hash 比对，不一致则删除并报错
- 切忌在 HTTP handler 中直接执行耗时合并 —— 应写入消息队列（如 Redis List）或启动 goroutine 异步处理，否则阻塞 Gin worker
分片合并真正难的不是代码，而是状态一致性：分片存储路径设计、失败重试标记、过期清理策略（比如 24 小时未完成的分片自动丢弃），这些比 io.MultiReader 拼接本身更易出错。
