context.Context在Go中用于控制HTTP流式请求的超时、取消和元数据传递，而非模型内部流控；正确用法是使用r.Context()、WithTimeout兜底、显式传业务参数、严格defer cancel()。
Go 语言上下文（context.Context）本身不参与“流式语言学习”这类 AI/ML 场景的模型训练或推理配置——它不是用来调参、加载模型或控制 token 流的。如果你在做基于 Go 的 LLM API 封装、服务代理、或后端请求编排，那 context.Context 才真正起作用：它管的是 HTTP 调用超时、流式响应中断、取消长连接、传递 traceID，而不是模型内部的 streaming 逻辑。
HTTP 流式响应中必须用 r.Context()，不能用 context.Background()
比如你用 Go 写一个转发 LLM 流式输出（SSE 或 chunked JSON）的代理服务，handler 里直接新建 context.Background() 是常见错误：
- 客户端断开连接时，
ctx.Done()不会触发，后端 goroutine 继续发数据，造成 goroutine 泄漏和资源浪费 - 无法注入 traceID、userID 等元数据，链路追踪断裂
- 上游网关设置的超时（如 30s）无法向下传递，下游模型可能跑满 5 分钟才停
正确做法是直接用 HTTP 请求自带的上下文：ctx := r.Context()，再传给下游 HTTP client 或数据库操作。
context.WithTimeout 适合控制单次流式请求总耗时
LLM 接口常返回流式响应（如 OpenAI 的 /v1/chat/completions + stream=true），但整个请求生命周期仍需硬性兜底：
立即学习“go语言免费学习笔记（深入）”；
- 用
context.WithTimeout(r.Context(), 45*time.Second)，而非WithDeadline—— 因为你知道“最多等 45 秒”，不是“必须在某个绝对时间点前结束” - 超时后，
http.Client.Do会收到context.DeadlineExceeded，自动关闭底层连接，避免 hang 住 - 注意：流式 body 的读取也必须在该 ctx 下进行，否则超时信号无法中断
io.Copy或json.Decoder.Decode
别用 context.WithValue 传 prompt、temperature 等业务参数
context.WithValue 只应承载轻量、请求级、只读元数据（如 traceID、userID、requestID），不是业务参数容器：
- 把
prompt、temperature塞进 context，会导致函数签名不清晰、难以单元测试、IDE 无法跳转参数定义 - 违反 “context 仅用于控制，不用于传参” 原则，后续加中间件或重试逻辑时极易出错
- 正确方式：显式作为函数参数传入，例如
callLLM(ctx, prompt, temperature)
defer cancel() 必须写，且只能在创建它的 goroutine 中调用
每次调用 context.WithCancel 或 context.WithTimeout 都会返回一个 cancel 函数，它不是可选配件：
- 漏掉
defer cancel()→ timer 不释放 → goroutine 泄漏 → 服务运行几小时后内存持续上涨 - 在子 goroutine 里调用
cancel()是安全的；但在另一个 goroutine 里 defer 它，会导致 panic 或静默失效 - 流式场景下尤其危险：一个 handler 启动 3 个并发流请求，每个都必须有自己的
cancel并各自 defer
最易被忽略的是：流式响应一旦开始写 header 和 body，就无法再靠 context 取消已发送的数据，但及时 cancel 至少能阻止后续 chunk 发送和后端计算继续 —— 这就是它存在的全部意义。
