gin本身不导致端口耗尽，因其作为服务端仅监听固定端口，不主动发起 outbound 连接；端口耗尽源于 handler 内使用 http.client 调用下游服务时未优化 transport（如 maxidleconnsperhost 默认仅2）且缺乏并发控制，导致大量短连接占用 ephemeral 端口。
为什么 Gin 本身不导致端口耗尽，但用它写的客户端会
Gin 是 HTTP 服务端框架，它监听固定端口（如 :8080），不主动向外发起连接，所以不会耗尽本地临时端口。真正出问题的，是你在 Gin 的 handler 里用 http.Client 调用其他服务（比如调下游 API、Redis、ETH 节点）——这些 outbound 连接才需要本地 ephemeral port。错误日志里出现 dial tcp: can't assign requested address，说明是 handler 内部发请求时端口不够用了，不是 Gin 启动失败。
必须重写 http.Transport：改掉那两个致命默认值
Go 标准库的 http.DefaultTransport 在高并发场景下等于没开连接复用：MaxIdleConnsPerHost 默认是 2，MaxIdleConns 默认是 100。哪怕你并发 50 个 goroutine 请求同一地址（如 localhost:8545），98% 的请求都会新建 TCP 连接，快速吃光 32768 个临时端口。
-
MaxIdleConnsPerHost至少设为 200（或按峰值并发 * 1.2 估算） -
MaxIdleConns必须同步放大，建议 ≥MaxIdleConnsPerHost× host 数量（单 host 场景可设为 500） -
IdleConnTimeout设为30 * time.Second以上，避免连接刚建好就被回收 - 如果走 HTTPS，顺手配好
TLSHandshakeTimeout和ExpectContinueTimeout
示例：
transport := &http.Transport{
MaxIdleConns: 500,
MaxIdleConnsPerHost: 200,
IdleConnTimeout: 30 * time.Second,
TLSHandshakeTimeout: 10 * time.Second,
}
client := &http.Client{Transport: transport}
别让 handler 无节制发请求：加信号量硬限流
即使 Transport 调优到位，如果一个 HTTP 请求触发 1000 个并发 client.Do()，连接池再大也扛不住——goroutine 泛滥会压垮内存、调度器，甚至触发系统级 too many open files。必须在 handler 入口就控并发。
- 用
golang.org/x/sync/semaphore，别自己写chan struct{}—— panic 分支漏Release()就永久卡死 - 初始化全局信号量，比如
sem := semaphore.NewWeighted(50)（每秒最多 50 个 outbound 请求） - 每个 outbound 请求前调
sem.Acquire(ctx, 1)，结束时defer sem.Release(1) - 配合
context.WithTimeout()，防止某个请求 hang 住整个信号量
OS 层不能跳过：内核参数要跟上
Go 层再优化，也绕不开 Linux 内核限制。常见疏漏：
-
net.ipv4.ip_local_port_range默认是32768 65535（仅 32768 个端口），生产环境应扩到1024 65535（注意避开 1–1023 特权端口） -
net.ipv4.tcp_fin_timeout默认 60 秒，TIME_WAIT 状态太长；可降至30或20加速端口回收 -
net.core.somaxconn和fs.file-max也要检查，避免被 ulimit 卡住
这些得进 /etc/sysctl.conf 持久化，重启后依然生效。
最易被忽略的是：Transport 调优和信号量必须同时存在。只改 Transport，goroutine 还是会泛滥；只加信号量，连接复用率低，端口还是撑不久。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
