分片上传与断点续传的关键在于文件唯一性识别和状态一致性：前端用SHA256哈希值标识文件，服务端据此查询已传分片；接收时禁用自动解析、直读request.Body流式落盘；合并前校验分片齐全性并加锁防竞态；分片大小推荐5–10MB，chunk_index从0开始，统一约定避免错位。
分片上传时如何保证文件唯一性和断点续传
关键在于服务端必须能识别同一个文件的多次上传请求，否则不同用户上传同名文件会互相覆盖。推荐用文件内容的 sha256（或 md5）哈希值作为全局唯一标识，前端在上传前先计算并携带该值；服务端收到首片时，检查 upload_id 是否已存在对应哈希记录——若存在，直接返回已上传的分片列表，前端跳过已传成功的部分。
实际操作中容易忽略两点：一是前端未对大文件做流式哈希（导致内存爆掉），应使用 crypto/sha256 + io.MultiReader 分块计算；二是服务端没校验分片序号连续性，比如收到第 1、3 片却跳过第 2 片，后续合并会失败。建议入库时强制要求 chunk_index 从 0 开始且递增，缺失则拒绝写入。
Go 后端如何安全接收并落盘分片文件
不要直接用 multipart.FormFile 读取整个分片到内存，尤其当单片大小达 10MB+ 时极易 OOM。正确做法是调用 request.MultipartReader() 获取流，再用 io.Copy 写入临时目录（如 /tmp/uploads/{upload_id}/{chunk_index}），同时限制单个请求体大小（http.MaxBytesReader）和总分片数（防止恶意构造海量小片耗尽磁盘 inode）。
常见错误包括：路径拼接未做 filepath.Clean 校验，导致攻击者通过 ../ 跳出目录；临时文件未设置 0600 权限，造成敏感分片被其他进程读取；忘记在写入失败时清理已存分片。建议封装一个 saveChunk 函数，内部自动处理 clean、权限、原子写入和失败回滚。
立即学习“go语言免费学习笔记（深入）”；
合并分片时如何避免竞态和文件损坏
多个客户端可能同时触发同一 upload_id 的合并请求，若不做同步，会导致重复合并或写入冲突。最简方案是用文件锁（flock）：打开目标文件后调用 syscall.Flock(fd, syscall.LOCK_EX)，合并完成再 LOCK_UN；更健壮的做法是用 Redis 实现分布式锁（SET upload:{id}:lock "1" NX EX 30），超时自动释放。
合并本身不能简单按序 cat，必须严格按 chunk_index 升序读取每个分片，用 os.OpenFile(..., os.O_WRONLY|os.O_CREATE|os.O_APPEND) 追加写入目标文件。遗漏点：未校验所有分片是否齐全（可用 SELECT COUNT(*) FROM chunks WHERE upload_id = ? 对比总片数），也未在合并后删除分片临时文件——残留分片会持续占用磁盘空间。
前端如何控制分片大小与并发策略
分片大小不是越大越好。实测发现 Chrome 对单个 fetch 请求的内存占用约等于分片大小 + 2× 头部开销，100MB 分片易触发浏览器内存警告；而太小（如 100KB）又因 HTTP 开销占比高、TCP 连接频繁重建，整体速度反而下降。推荐 5–10MB，配合 3–5 路并发（Promise.allSettled 控制），并监听 upload.onprogress 动态降级（网络波动时自动减并发）。
容易踩的坑：前端未处理 413（Payload Too Large）错误，服务端返回该状态码时直接失败而非提示“请调整分片大小”；上传完成后未主动清空 FileReader 缓存，导致后续上传同一文件时哈希计算复用旧缓存；分片序号从 1 开始而非 0，和服务端逻辑错位。务必统一约定 chunk_index 从 0 开始计数。
真正麻烦的是跨域场景下预检请求（OPTIONS）被反复触发——每个分片都带自定义 header（如 X-Upload-ID），浏览器会为每个分片发一次 OPTIONS，拖慢首屏。解决方案是服务端明确声明 Access-Control-Allow-Headers: X-Upload-ID,X-Chunk-Index 并缓存预检结果（Access-Control-Max-Age: 86400）。
