用 http.defaultclient 并发请求需自定义 transport：调大 maxidleconns 和 maxidleconnsperhost，关闭 dns 频繁解析，限制 goroutine 数量防 oom，必须 close resp.body 防 fd 泄漏，并固定 gomaxprocs、禁用 gc 以减少调度干扰。
怎么用 http.DefaultClient 发起并发请求不崩
Go 的 http.DefaultClient 默认复用连接，但压测时若不调优，很快会卡在 DNS 解析、连接池耗尽或 TCP TIME_WAIT 堆积上。关键不是“能不能发”，而是“发完能不能收、收得稳不稳”。
-
http.DefaultClient.Transport必须自定义：默认MaxIdleConns和MaxIdleConnsPerHost都是 100，压测 500 并发时直接排队等连接 - DNS 缓存要关或设长：默认
net.Resolver不缓存，高频域名解析会阻塞 goroutine；可配Transport.DialContext+net.Dialer.Timeout控制建连超时 - 别用
time.Sleep控制 QPS：goroutine 启太多又睡不齐，实际并发毛刺大；改用time.Ticker或带限速的 worker 池
示例关键配置：
tr := &http.Transport{
MaxIdleConns: 2000,
MaxIdleConnsPerHost: 2000,
IdleConnTimeout: 30 * time.Second,
TLSHandshakeTimeout: 10 * time.Second,
}
client := &http.Client{Transport: tr}为什么 goroutine + http.Do 写法容易 OOM
常见写法是 for 循环里直接 go func() { client.Do(req) }()，看着简洁，实则危险——没做并发控制，瞬间几千 goroutine 启动，内存暴涨，调度器反成瓶颈。
- 每个 goroutine 至少占 2KB 栈空间，10k 并发 ≈ 20MB 内存起步，还没算响应体缓冲
-
http.Do是同步阻塞的，goroutine 等响应期间仍驻留，无法被 GC 回收 - 错误不收集：HTTP 错误码、timeout、connection refused 全被吞掉，压测结果失真
正确做法是加 channel 控制并发数，比如用带缓冲的 sem channel：
立即学习“go语言免费学习笔记（深入）”；
sem := make(chan struct{}, 100) // 限制 100 并发
for i := 0; i < total; i++ {
sem <- struct{}{}
go func() {
defer func() { <-sem }()
resp, err := client.Do(req)
// 处理 resp/err
}()
}
http.Response.Body 不 Close() 会导致什么
压测中常忽略 resp.Body.Close()，后果不是立刻报错，而是连接无法复用、文件描述符泄漏、后续请求变慢甚至失败。
- HTTP/1.1 默认 keep-alive，
Body不关 → 连接卡在 “idle” 状态，进不了连接池复用队列 - Linux 默认单进程 1024 fd 限制，压测几分钟就 hit
too many open files - 即使用了
io.Copy(ioutil.Discard, resp.Body)，也必须跟resp.Body.Close()，否则底层 TCP 连接不释放
安全写法（带错误检查）：
resp, err := client.Do(req)
if err != nil {
// 记录 err
return
}
defer resp.Body.Close() // 注意：这里 defer 在 goroutine 里才有效
body, _ := io.ReadAll(resp.Body)
// 后续处理 body怎么让压测结果不被 Go runtime 调度干扰
短时高压下，GC 频繁触发、P 数量波动、GMP 调度抖动，会让 p99 延迟虚高。这不是代码问题，是观测方式问题。
- 别只看平均 RT：压测 10 秒，前 2 秒 GC STW 可能拉高整体均值，掩盖真实服务瓶颈
- 运行前固定 GOMAXPROCS：比如
runtime.GOMAXPROCS(runtime.NumCPU())，避免测试中途动态扩缩 P - 禁用后台 GC（仅限压测进程）：
debug.SetGCPercent(-1)，测完再恢复；或用GODEBUG=gctrace=1观察 GC 频次 - 结果采集避开首尾 1 秒：warmup 和 cooldown 阶段数据噪声大，直接切片丢弃
复杂点在于：你永远分不清是服务慢了，还是 Go 自身调度卡了。所以压测时务必同时采集 runtime.ReadMemStats 和 debug.ReadGCStats，对照看。
