端口冲突时先用lsof或netstat查PID,再检查代码是否重复调用ListenAndServe;HTTP请求卡住需设Transport超时并启用GODEBUG调试;连接重置需手动Close而非依赖defer;pprof需结合trace和中间件埋点定位慢handler。

net/http 服务启动失败时怎么快速定位端口冲突
Go 的 http.ListenAndServe 默认遇到端口被占会直接 panic 并输出 listen tcp :8080: bind: address already in use,但不显示是哪个进程占的。别急着杀进程,先确认是不是自己启了两次:
- 用
lsof -i :8080(macOS/Linux)或netstat -ano | findstr :8080(Windows)查占用进程 PID - 检查代码里是否重复调用了
http.ListenAndServe,尤其是测试时忘记注释掉旧的go http.ListenAndServe(...) - 开发中建议加超时和错误处理:
if err := http.ListenAndServe(":8080", nil); err != nil && !errors.Is(err, http.ErrServerClosed) { log.Fatal(err) }
HTTP 请求卡住、超时却没报错,怎么抓真实请求流
Go 的 http.Client 默认不打印请求/响应,容易误判是服务端问题。实际可能是 DNS 解析慢、TLS 握手卡住,或代理配置错误。
- 启用调试日志:设置环境变量
GODEBUG=http2debug=1(看 HTTP/2 流),或用curl -v对比验证是否 Go 客户端特有问题 - 自定义
http.Transport加日志钩子,比如在DialContext和TLSHandshake回调里打点 - 关键参数要显式设:超时必须设
Timeout、IdleConnTimeout、TLSHandshakeTimeout,否则默认是 0(无限等待)
net.Conn 层连接异常断开,为什么 read: connection reset by peer 不触发 defer
用 conn.Read 读取时遇到对端强制关闭(如 Nginx 502、K8s readiness probe 失败后 kill),返回 read: connection reset by peer,但你的 defer conn.Close() 可能根本没执行——因为 panic 或 goroutine 被粗暴终止了。
- 永远不要依赖 defer 关闭底层连接;在
Read或Write返回错误后立刻conn.Close() - 用
net.Error类型断言判断临时错误:if n, err := conn.Read(buf); err != nil { if netErr, ok := err.(net.Error); ok && netErr.Timeout() { // 处理超时 } conn.Close() // 立即关 } - 如果用
bufio.Reader包装,注意io.EOF是正常结束,而read: connection reset by peer是底层 syscall 错误,二者处理逻辑不同
pprof 能看到 CPU 高,但不知道哪个 HTTP handler 在拖慢整体响应
默认 net/http/pprof 注册在 /debug/pprof/,但 profile 数据是全量聚合的,看不出具体路由耗时。得结合 trace 和自定义标签。
立即学习“go语言免费学习笔记(深入)”;
- 启动时注册 pprof:
import _ "net/http/pprof",然后跑go tool pprof http://localhost:6060/debug/pprof/profile?seconds=30 - 对关键 handler 手动埋点:
func myHandler(w http.ResponseWriter, r *http.Request) { ctx := r.Context() ctx = trace.WithRegion(ctx, "myHandler") defer trace.EndRegion(ctx) // ... } - 更实用的是加中间件记录每个 handler 的耗时和状态码,写入结构化日志(如
zap),再用grep或 Loki 查慢请求
http.Transport.MaxIdleConnsPerHost 设太小导致频繁建连,或者 TLS session 复用失败又没日志——这些得靠 httptrace 或 Wireshark 抓包才看得清。











