本文详解 go 使用 goproxy 时因未校验 `*http.response` 是否为 nil 导致的 `runtime error: invalid memory address or nil pointer dereference` panic，并提供健壮、可复用的响应处理模板。
在基于 goproxy 构建 HTTP 代理（如 API 请求/响应改写、日志审计、流量调试等场景）时，开发者常通过注册 FuncRespHandler 来拦截并处理上游响应。然而，一个极易被忽略的关键事实是：response 参数并非总是非空——当代理与目标服务器通信失败（如连接超时、DNS 解析失败、TLS 握手异常、服务端主动拒绝等）时，goproxy 明确约定将传入 nil 的 *http.Response，并将具体错误信息存于 ctx.RoundTrip.Error 字段中。
若直接对 response.Status 等字段进行解引用（如 log.Printf("Response: %s", response.Status)），而未事先判空，Go 运行时便会触发经典的 nil pointer dereference panic，导致当前 goroutine 崩溃，甚至中断整个代理服务。
⚠️ 已弃用 — 该技能已拆分为两个独立技能，以提升模块化程度：**webchat-https-proxy**（HTTPS/WSS 反向代理）和 **webchat-voi...**
✅ 正确做法：始终校验 response 是否为 nil
以下是一个生产就绪的响应处理器示例，兼顾安全性、可观测性与可维护性：
func viewResponse(response *http.Response, ctx *goproxy.ProxyCtx) *http.Response {
if response == nil {
// 处理请求失败场景：记录错误，不 panic
if ctx.RoundTrip.Error != nil {
log.Printf("[Proxy] Request to %s failed: %v",
ctx.Req.URL.String(), ctx.RoundTrip.Error)
} else {
log.Printf("[Proxy] Request to %s failed: unknown error (response=nil, RoundTrip.Error=nil)",
ctx.Req.URL.String())
}
return nil // 或返回自定义错误响应，如 http.Error(...)
}
// 正常响应路径：安全访问 response 字段
log.Printf("[Proxy] Response from %s: %s (%d bytes)",
ctx.Req.URL.Host, response.Status, response.ContentLength)
// ✅ 示例：修改响应体（需先读取并重写 Body）
// 注意：此处仅为示意，实际需考虑流式处理、内存限制、Content-Encoding 等
// bodyBytes, err := io.ReadAll(response.Body)
// if err == nil {
// modifiedBody := bytes.ReplaceAll(bodyBytes, []byte("old"), []byte("new"))
// response.Body = io.NopCloser(bytes.NewReader(modifiedBody))
// response.ContentLength = int64(len(modifiedBody))
// response.Header.Set("X-Modified-By", "goproxy")
// }
return response
}⚠️ 关键注意事项
- 不可跳过判空：response == nil 是合法且常见状态，绝非“异常分支”，必须作为主逻辑分支显式处理；
- 错误来源唯一性：ctx.RoundTrip.Error 是获取请求失败原因的唯一可信来源，不应依赖 response.StatusCode 或其他字段；
- 返回值语义：函数返回 nil 表示代理应中止响应传递（可配合 goproxy.NewResponse 构造自定义错误页）；返回原 response 或新 *http.Response 则继续转发；
- 避免副作用：在 response == nil 分支中，切勿尝试访问 response.* 任何字段（包括 response.Request, response.Header 等），否则仍会 panic；
- 日志上下文增强：建议在日志中包含 ctx.Req.URL、ctx.Req.Method 等上下文，便于问题定位与链路追踪。
? 总结
nil pointer dereference 在 goproxy 开发中本质是防御性编程缺失的体现。牢记 “所有由框架回调传入的指针参数都可能为 nil” 这一黄金法则，将 if response == nil { ... } 作为每个 FuncRespHandler 的第一道守门员，即可彻底规避此类 panic。这不仅是代码健壮性的保障，更是构建高可用代理服务的基石。
