端口冲突时先用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 抓包才看得清。 
