Context 不能直接序列化传递到断点续传的后续请求中，因其是内存中生命周期受限的对象，无法 encode、保存或跨进程/跨 HTTP 请求传递；断点续传应持久化 upload_id、offset 和临时文件路径，每次请求用 r.Context() 新建带超时的子 Context 处理分片。
Context 不能直接序列化传递到断点续传的后续请求中
Go 的 context.Context 是内存中生命周期受限的对象，它依赖 goroutine 栈和内部的 cancel 通道，**无法被 encode、保存或跨进程/跨 HTTP 请求传递**。你在断点续传（比如分块上传、HTTP Range 续传）中看到的“传递 Context”，实际是指：在当前请求处理链路中持续使用同一个 context.Context 控制超时与取消，而不是把 Context 存进文件或 header 里“传给下一次请求”。
断点续传场景下 Context 的正确用法
典型场景是服务端接收大文件分片（如 /upload/chunk?offset=1048576），每个请求需独立带超时、可被整体取消（例如用户取消上传）。此时 Context 应由入口处生成，并贯穿本次 HTTP 处理全程：
- 用
context.WithTimeout(r.Context(), 30*time.Second)基于原始请求 Context 衍生带超时的子 Context - 将该子 Context 传给文件写入、校验、存储等所有阻塞操作（如
io.Copy、os.WriteAt、storage.PutObject） - 不要尝试把 Context 保存到数据库或文件元信息里——下个分片请求进来时，它天然拥有自己的新
r.Context() - 若需“全局取消”多个分片（如前端点击取消整个上传），应配合外部信号（如 Redis key、内存 map + mutex）+ 每次请求检查该信号，而非依赖 Context 传递
常见错误：试图把 Context 当作状态参数透传
以下写法是错的：
// ❌ 错误：试图把 context.Context 作为字段存进结构体并持久化
type UploadSession struct {
ID string
Offset int64
Ctx context.Context // 这个字段毫无意义，且会引发 panic 或静默失效
}
错误现象包括：
立即学习“go语言免费学习笔记（深入）”；
- 程序 panic：Context 实现了
fmt.Stringer但内部含未导出字段，JSON marshal 报json: unsupported type: context.cancelCtx - 静默失效：你存了个空 Context（
context.Background()），后续调用ctx.Done()永远不触发 - 并发 panic：多个 goroutine 同时调用
cancel()导致 context 包内部竞态
真正需要“传递”的是可恢复的状态，不是 Context
断点续传真正要持久化的只有三类东西：
- 文件唯一标识（如
upload_id或 hash） - 已写入偏移量（
offset，单位字节） - 临时文件路径或对象存储 key（如
/tmp/upload_abc123.part）
这些才是你应该存进数据库、Redis 或本地磁盘的字段。每次新请求来时，根据 upload_id 查出 offset，再用 r.Context() 新建一个带超时的 Context 去处理本次分片——这才是干净、安全、符合 Go 习惯的做法。
容易被忽略的一点：如果上传过程涉及多个微服务（如网关 → 上传服务 → 对象存储代理），那 Context 只能在单跳 HTTP 调用中通过 X-Request-ID 和超时 header 间接对齐；跨服务的取消必须靠业务层重试/幂等 + 状态轮询，不能指望 Context 穿透。
