GoLand 难以静态识别 net.Conn 泄漏，因其不内置专用检测规则，仅能高亮未调用 Close()，无法判断控制流中 defer 是否被 panic 或 return 绕过，也不能推断 conn 是否为 nil，故需依赖 go vet + staticcheck 等工具补足。
为什么 net.Conn 泄漏在 GoLand 里很难被静态识别
GoLand 本身不内置“未关闭连接”检测规则，因为 Close() 调用是否遗漏，本质上依赖控制流分析（比如 panic 后是否仍执行 defer conn.Close()）、资源生命周期判断（连接是否被提前 return 或异常路径绕过），而这些超出了 IDE 的基础语法检查能力。它能高亮未调用的 Close()，但无法判断“该不该关”或“有没有可能漏关”。
用 go vet + staticcheck 补齐关键检查
真正能发现典型泄漏的是命令行工具：go vet -vettool=$(which staticcheck) 或单独运行 staticcheck。它们会标记以下模式：
-
net.Conn类型变量在函数末尾未显式调用Close()，且无defer conn.Close() -
http.Response.Body被读取后未调用resp.Body.Close()（staticcheck的SA1006规则） -
sql.Rows、http.Request.Body等常见资源类型同理
在 GoLand 中，可配置 External Tools 将 staticcheck 集成进右键菜单，或直接终端运行：staticcheck ./...。注意：它不会检查 defer 是否被 return 或 panic 绕过——这需要人工审查。
GoLand 2026.1.1
下载
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
在 GoLand 里快速定位疑似泄漏点
利用 IDE 的结构化搜索能力缩小范围，比盲目扫代码更高效：
- 按符号搜索
net.Dial、http.Get、http.Post、sql.Open—— 这些是连接创建入口 - 对每个结果，打开所在文件，用
Ctrl+F搜.Close()或defer.*Close，看是否紧邻创建逻辑 - 特别留意
if err != nil { return }前是否有defer conn.Close()；若defer写在错误检查之后，panic 或 return 会跳过它 - 检查
http.Client.Do返回的*http.Response，确认每个resp.Body.Close()都在if resp != nil保护下，且不在defer里裸写（否则 resp 为 nil 时 panic）
最容易被忽略的陷阱：defer 位置和 nil 安全
很多人以为写了 defer conn.Close() 就万事大吉，但实际出问题的往往是这两处：
-
conn, err := net.Dial(...); if err != nil { return }之后才写defer conn.Close()—— 此时conn可能为nil，调用nil.Close()panic -
defer func() { if conn != nil { conn.Close() } }()看似安全，但如果conn是局部变量且作用域外不可见，GoLand 无法推断其非 nil 性，静态检查也常漏报 - HTTP 客户端复用时，
resp.Body必须每次读完立刻关，不能靠 defer 延迟到函数结束——因为resp可能被重用或缓冲区已释放
真实泄漏往往藏在分支多、error handling 复杂的 handler 函数里，而不是主流程。盯住 net.Conn 和 io.ReadCloser 类型的赋值语句，逐个验证 close 路径，比依赖工具更可靠。
