Go语言处理大文件网络传输的核心是确保并发安全、数据完整与资源可控：必须用io.ReadAt替代bufio.Reader实现线程安全随机读，分片上传需限流（≤5并发）、带重试、校验offset与长度，服务端状态与客户端预期严格比对后才合并。
Go 语言处理大文件网络传输，核心不是“能不能并发”，而是“并发时怎么不崩、不乱、不丢”。盲目开 goroutine 上传分片，大概率触发连接耗尽、服务端 missing part、内存暴涨或空块 panic。
用 io.ReadAt 并发读文件，别碰 bufio.Reader
多个 goroutine 同时读同一文件的不同 offset，必须用 io.ReadAt —— 它是线程安全的随机读，不依赖文件内部偏移状态。而 bufio.Reader 是顺序读缓冲器，封装后调 ReadAt 会失效，且并发调 Read() 会互相干扰位置。
- 每次读前显式计算
offset := int64(chunkIndex) * chunkSize，传给f.ReadAt(buf[:], offset) - 必须检查
n < len(buf)：最后一块不足chunkSize时，buf剩余部分是脏数据，得用buf[:n]截断再传 - 错误时只容忍
io.EOF；err == nil && n == 0是非法空块，应直接跳过或报错
HTTP 分片上传必须用 multipart 或 application/octet-stream
把分片内容 base64 编码塞进 JSON 字段里？这是最常见也是最危险的写法。服务端拒收、内存翻倍、GC 频繁，三连击。
- 若服务端支持
multipart/form-data：用mime/multipart.Writer构建表单，一个字段传chunk_id，一个字段传bytes.NewReader(chunkData) - 若服务端接受 raw body：设
req.Header.Set("Content-Type", "application/octet-stream")，并用req.Body = io.NopCloser(bytes.NewReader(chunkData)) - 绝对不要用
fmt.Sprintf拼接 multipart boundary 和二进制数据——换行、编码、边界对齐全错，400 Bad Request 甩脸就来
并发上传必须限流 + 全部成功才合并
开 50 个 goroutine 同时上传 50 个分片？网络抖动下，可能 30 个超时、10 个成功、10 个被重试压垮连接池。更糟的是：你收到 49 个 success 响应就去调合并接口，服务端返回 404 Missing Part —— 因为第 27 块其实失败了但没重试完。
立即学习“go语言免费学习笔记（深入）”；
- 用
semaphore（如golang.org/x/sync/semaphore）控制最大并发数，生产环境建议 ≤ 3～5 - 每个分片上传需带重试（最多 2 次），失败要记录 index，最后汇总未成功列表
- 合并动作必须等所有分片返回 success（含重试后），且服务端
/upload/status?file_id=xxx返回的已传列表与客户端预期完全一致，才可发起
gRPC 流式上传必须定义 stream，别用 unary
写成 rpc Upload(FileRequest) returns (FileResponse) 就等于宣告 OOM。gRPC 底层会攒完整请求体再解包，1GB 文件进来，内存先吃掉 1.2GB。
- 必须定义为
rpc Upload(stream Chunk) returns (UploadResult)（客户端流）或rpc Upload(stream Chunk) returns (stream ChunkAck)（双向流） -
Chunk消息里只放bytes data和uint64 offset（或int32 seq），别塞文件名、hash、时间戳到每块里 - 发送前检查
len(data) == 0，空 chunk 在某些服务端 protobuf 解析逻辑里会 panic
真正难的从来不是“怎么切块”，而是“怎么让 100 个块在并发、中断、重试、服务端异步处理的混合环境下，最终拼出和原文件 bit-for-bit 完全一致的结果”——这要求每一块的 offset、长度、校验值都严格对齐，且任何环节都不能绕过状态比对直接信任本地缓存。
