go分片上传需手动控制读取偏移与长度：用os.open+file.seek定位，io.copyn安全切分；分片标识推荐sha256(file.name())[:8]+序号，固定大小（如5mb），最后一片≤5mb，避免内存溢出。
分片上传时如何正确切分文件并生成唯一标识
Go 本身不提供开箱即用的分片上传逻辑，必须手动控制读取偏移和长度。关键在于：每个分片需携带可复原的元信息（如文件名、总片数、当前序号、分片大小），否则合并时无法排序或校验。os.Open 后用 file.Seek 定位起始位置，再用 io.CopyN 或循环 Read 写入分片文件，避免一次性加载全量到内存。
常见错误是直接按字节数硬切，却忽略文件内容边界（比如切在 UTF-8 多字节字符中间），但对二进制文件（如图片、压缩包）无需考虑编码，可安全按字节切分。推荐使用固定分片大小（如 5MB），最后一片大小 ≤ 5MB。
- 分片文件命名建议含哈希前缀（如
sha256(file.Name())[:8]）+ 序号 + 扩展名，避免同名文件冲突 - 务必记录原始文件名、
Content-Type、总大小，这些需随分片一起传给服务端或存入本地元数据文件 - 不要依赖
os.Stat().Size做分片计数——若文件被其他进程写入中，该值可能不准；应先Seek(0, io.SeekEnd)获取实时大小
服务端接收分片时如何防重放和保证顺序
HTTP 接口接收到分片后，不能直接落地存储，必须验证：分片序号是否连续、是否重复提交、是否缺失。最简方案是将每个分片以 upload_id/chunk_0001.bin 形式暂存，并维护一个 JSON 元数据文件 upload_id/meta.json 记录已收片列表、总片数、原始文件名等。
容易踩的坑是并发上传同一文件时，多个客户端生成相同 upload_id 导致覆盖。解决方式：服务端生成 UUID 作为 upload_id，前端在首次请求时获取并用于后续所有分片请求的 URL 路径或 Header 中。
- 接收分片接口必须校验
Content-MD5或X-Chunk-HashHeader，防止网络损坏或中间篡改 - 分片序号建议从 0 开始（便于数组索引），且强制要求客户端按序上传——服务端不负责排序，只做存在性检查
- 若某分片失败重传，服务端应幂等处理：检查该分片是否已存在且大小/哈希一致，一致则直接返回成功，不重复写磁盘
合并分片时如何避免 I/O 阻塞和内存溢出
合并不是把所有分片读进内存再写，而是打开目标文件后，按序打开每个分片文件，用 io.Copy 流式写入。这样内存占用恒定（约几 KB 缓冲区），与文件总大小无关。
注意：合并前必须校验所有分片是否齐全、大小是否匹配预期（除最后一片外，其余片大小应严格等于设定值）。缺失或损坏的分片应直接报错退出，不尝试填充或跳过。
- 使用
os.O_CREATE | os.O_WRONLY | os.O_APPEND打开目标文件，但更推荐先创建空文件，再用file.WriteAt精确写入每一片到对应偏移，避免顺序依赖 - 合并过程应加锁（如
sync.Mutex）或使用临时文件名（final_file.tmp），合并完成后再os.Rename，防止程序崩溃导致半成品暴露 - Linux 下可考虑用
syscall.CopyFileRange（Go 1.19+）实现零拷贝合并，但需确保源和目标文件系统支持，且分片文件未被 mmap 或锁定
客户端如何断点续传并感知上传进度
Go 客户端（如用 net/http）实现断点续传，核心是记录已成功上传的分片序号。每次上传前先向服务端发 HEAD /upload/{upload_id}/status 查询已存在分片列表，然后跳过已传部分。
进度反馈不能只靠 HTTP 响应状态码——需解析服务端返回的 JSON（如 {"uploaded_chunks": [0,1,3], "total_chunks": 10}），再计算百分比。注意：HTTP/1.1 默认不支持上传进度回调，需手动封装 io.Reader 实现带计数的包装器。
- 用
io.MultiReader或自定义struct{ r io.Reader; cb func(int64) }在每次Read后触发回调，避免阻塞主逻辑 - 上传请求应设置超时（
http.Client.Timeout）和重试（最多 2 次），但重试仅限网络错误，非 4xx 错误（如 409 Conflict 表示分片已存在） - 不要把 upload_id 存在全局变量里——多文件上传时会串，应为每个上传任务维护独立状态结构体
实际最难的部分不是切和合，而是元数据一致性：客户端认为传完了，服务端 meta.json 却没刷盘成功；或者合并进程被 kill，留下不完整文件。这些必须靠原子操作+校验兜底，不能靠“大概率没问题”。
