Go语言是构建生产级压测工具的首选，因其goroutine轻量、http.Client默认复用连接、并发控制直观；避免sleep误判并发，需用信号量限流并显式设timeout。
Go 语言在压力测试场景中不是“用来学习的语言”，而是直接用于构建真实压测工具的生产级选择——它不靠语法糖或教学友好度胜出，靠的是 goroutine 调度开销低、http.Client 默认复用连接、sync.WaitGroup 和 channel 控制并发流足够直观这三点，让开发者能快速写出可跑、可调、可嵌入 CI 的压测逻辑。
为什么不用 Go 写压测脚本反而更难？
常见误区是把 Go 当成“要学很久才能上手的系统语言”，其实恰恰相反：
-
goroutine启动成本约 2KB 栈空间，比 Python 线程（MB 级）或 Java 线程（OS 级调度）轻量得多，1000 并发 ≈ 2MB 内存，不会一跑就 OOM -
net/http默认启用连接池，http.DefaultClient复用 TCP 连接，不用手动管理Keep-Alive或重写底层 transport - 没有运行时解释开销（不像 Python/JS），编译后二进制直接执行，QPS 更稳定、延迟抖动小——这对识别真实服务瓶颈至关重要
并发数设多少才不假？关键看 time.Sleep 和 client.Timeout
很多初学者跑出“10 万 QPS”但结果无效，问题出在没区分「请求生成速率」和「真实并发压力」：
- 如果代码里写
time.Sleep(100 * time.Millisecond)，那即使开 1000 个goroutine，实际每秒最多发 10 个请求——并发数只是幻觉 -
http.Client的Timeout必须显式设置（如5 * time.Second），否则失败请求会卡住goroutine，导致后续请求堆积、统计失真 - 真正模拟高负载，应去掉 sleep，靠
semaphore := make(chan struct{}, N)控制最大并发连接数，再配合for time.Since(start) 持续发压
sync.WaitGroup + channel 统计容易漏掉什么？
最常被忽略的是 channel 缓冲区大小与关闭时机的匹配：
立即学习“go语言免费学习笔记（深入）”；
- 声明
results := make(chan Result, concurrency)时，缓冲区太小（比如只设 1）会导致发送阻塞，goroutine卡在results ，主 goroutine 等不到所有结果就提前退出 - 用
go func() { wg.Wait(); close(results) }()是安全的，但若改成defer close(results)在每个 worker 里执行，会 panic：close 已关闭的 channel - 错误统计必须包含
resp.StatusCode和err != nil两种失败路径——HTTP 500 返回不算 err，但业务上就是失败
真正卡住人的从来不是语法，而是对「并发 ≠ 并行」「连接池 ≠ 无限连接」「超时 ≠ 重试」这些底层契约的理解偏差。写压测代码时，每一行都在暴露你对网络栈、Go runtime 和目标服务真实能力的认知深度。
