必须用 WithContext 替换请求上下文，因为 *http.Request 不可变且 Context 是副本；需显式接收返回的新请求，否则替换失效；Body 不重置读取位置，替换前应确保未读取或重建 Body。
为什么要用 WithContext 替换请求上下文
Go 的 *http.Request 是不可变的（immutable），但某些中间件、测试或超时控制场景下，你确实需要替换它的 Context —— 比如注入追踪 ID、覆盖超时时间、或在测试中模拟 cancelable 上下文。直接改 req.Context() 返回的值没用，因为那是副本；必须用 WithContext 构造新请求对象。
WithContext 不会修改原请求，必须重新赋值
这是最常踩的坑：调用 req.WithContext(newCtx) 后，req 本身没变，返回的是一个全新的 *http.Request。如果忘了接住返回值，后续逻辑仍用旧请求，上下文替换就失效了。
常见错误写法：
req.WithContext(context.WithTimeout(req.Context(), 5*time.Second)) // ❌ 丢弃了返回值
正确做法：
- 显式接收返回值：
req = req.WithContext(...) - 若在中间件中传递，确保下游拿到的是新请求：
next.ServeHTTP(w, req.WithContext(...)) - 注意：原
req的所有字段（URL、Header、Body 等）都会被浅拷贝，但Body不会重放 —— 如果你已读过 Body，新请求的 Body 仍是 EOF 状态
替换上下文后，Body 和 Form 相关操作可能出错
WithContext 创建的新请求共享原始 Body 底层 reader，但不重置读取位置。这意味着：
- 如果原请求已调用过
req.ParseForm()或io.ReadAll(req.Body)，新请求的Body已到 EOF，再次读取会得到空内容或io.EOF -
req.FormValue、req.PostFormValue在未解析前会自动触发ParseForm，但如果 Body 已耗尽，就会静默失败或返回空字符串 - 安全做法：在替换上下文前，确保 Body 尚未读取；或提前用
httputil.DumpRequest备份，或用io.NopCloser(bytes.NewReader(buf))重建 Body
测试中替换上下文要小心 CancelFunc 生命周期
测试里常用 context.WithCancel 或 WithTimeout 注入可控上下文，但要注意：
- 不要在测试函数返回后调用
cancel()—— 若请求还在处理（比如 goroutine 异步读 Body），可能引发 panic：“context canceled” 被误判为业务错误 - 推荐用
context.WithTimeout并让超时自动清理，避免手动 cancel - 若必须手动 cancel，请确保 cancel 调用发生在请求生命周期结束之后（例如用
sync.WaitGroup等待 handler 返回）
真正麻烦的不是怎么换上下文，而是换完之后 Body 是否还能读、cancel 是否来得及、以及新旧请求对象是否被意外混用 —— 这些细节不验证，线上就容易出现偶发的空参数或超时不生效。
