Linux默认connect超时约63秒，因SYN重试5次、指数退避（1-2-4-8-16s），需显式设置ConnectTimeout等细粒度超时参数规避。
connect超时直接卡65秒？Linux底层重试策略必须绕开
默认用 net/http 或第三方 HTTP 客户端发请求时，若远端无响应，connect 阶段会走系统级 TCP 重试——Linux 默认 5 次，间隔翻倍（1s→2s→4s→8s→16s），总耗时约 63 秒 + 建连开销，实际表现就是“卡住一分多钟才报错”。这不是 Iris 的问题，是操作系统行为。
解决办法只有一个：不依赖系统默认，显式控制连接建立阶段的超时。
- 用
http.Client时，必须设置Timeout或更细粒度的Transport.DialContext+context.WithTimeout - 别只设
Timeout，它同时约束连接、读、写；生产环境推荐拆开：ConnectTimeout（建议 3–5s）、ReadTimeout（按业务响应预期设，如 10s）、WriteTimeout（通常 5s 足够） - 如果用的是
fasthttp（Iris 可选底层），注意其Client.ReadTimeout/WriteTimeout不包含 connect 阶段，仍需通过Client.Dial自定义带超时的拨号函数
retry逻辑写在中间件里？别碰这个坑
Iris 的中间件（iris.Handler）是面向 HTTP 请求生命周期的，不是为封装下游 API 调用设计的。把重试逻辑塞进中间件，会导致：重试失败后无法返回原始错误上下文、无法按下游状态码（如 429/503）差异化处理、重试次数和延迟参数难以透传到具体业务 handler 中。
正确做法是把重试封装成独立的客户端方法，由业务 handler 显式调用：
- 用
tenacity（Python）或backoff（Go）这类专注重试的库，而非自己写 for+sleep - 重试判定必须区分错误类型：
connection refused和read: connection reset by peer可重试；400 Bad Request或401 Unauthorized绝对不可重试 - 避免在重试中重复解析 request body——Iris 的
ctx.ReadJSON是单次消费，重试前得缓存原始字节或结构体
429限流重试要加抖动，否则触发重试风暴
大模型或 SaaS 平台返回 429 Too Many Requests 时，如果所有实例都按相同策略（比如固定等 1 秒）重试，瞬间并发会翻倍，可能直接压垮对方限流器，形成恶性循环。
必须引入随机抖动（jitter）：
- 指数退避基础公式：
delay = min(base * 2^attempt, max_delay)；加上 jitter 后变为：delay *= random.uniform(0.5, 1.5) - 别用
time.Sleep硬等——在 Iris 的异步 handler（iris.Async）中，应改用time.AfterFunc或context.AfterFunc避免阻塞协程 - 记录每次重试的
Retry-Afterheader 值，优先尊重服务端建议，比本地计算更可靠
云函数调用海外 API 超时？出口 IP 问题比超时配置更致命
如果你在腾讯云 SCF、阿里云 FC 或 AWS Lambda 上跑 Iris（或任何 Go Web 框架），调用海外 API 频繁 ReadTimeout，大概率不是代码没设 timeout，而是出口 IP 被对方 WAF 拦截或限速。
典型现象：本地跑 300ms，云端跑 30s 超时；抓包发现 TLS 握手阶段就卡住甚至 RST。
- 先验证：在 Iris handler 里用
http.Get("https://ipinfo.io/json")打印当前出口 IP，查 ASN 是否属于云厂商（如 AS16509 是 AWS） - 不要试图“加大 timeout”硬扛——这是掩耳盗铃。真实链路丢包率高、TLS 握手被限，再长的 timeout 也等不来响应
- 可行解只有两个：① 挂代理网关（住宅 IP 或数据中心白名单 IP）；② 改用云厂商提供的全球加速（GA）或 NAT 网关（部分支持固定出口 IP）
超时和重试只是表象，网络出口质量才是根因——这点在 Serverless 环境下最容易被忽略。
