在性能验证环节中，不少团队依赖现成压测二进制文件，但当业务接口带有复杂签名头或需要动态令牌时，外部工具往往难以贴合逻辑。使用Go语言从零实现一个HTTP压测工具，不仅能把鉴权函数直接写进请求构造过程，还能精细控制并发模型与采集指标。下面我们先看一个基础的工具运行示意图。
并发模型与请求发射器设计
Go语言实现压测核心在于goroutine的轻量特性。每一个虚拟用户可以用一个goroutine表达，通过sync.WaitGroup来等待全部任务结束。如果只是简单循环启动几万个goroutine，在短时间内会产生大量TCP连接，可能触发本地端口范围耗尽。更稳妥的做法是使用协程池配合任务队列，限制同时活跃的请求数量。
下面的示例展示了一个最基础的发射器：主函数根据设定的并发数开启固定数量的worker，每个worker从任务通道读取目标地址并发送请求。这里用http.Client并复用Transport以提升连接效率。注意要把DisableKeepAlives设为false，否则每次请求都重新握手。
package main
import (
'fmt'
'net/http'
'sync'
'time'
)
func worker(id int, tasks chan string, wg *sync.WaitGroup, client *http.Client) {
defer wg.Done()
for url := range tasks {
start := time.Now()
resp, err := client.Get(url)
if err != nil {
fmt.Printf('worker %d error: %vn', id, err)
continue
}
resp.Body.Close()
fmt.Printf('worker %d cost %vn', id, time.Since(start))
}
}
func main() {
var wg sync.WaitGroup
tasks := make(chan string, 100)
client := &http.Client{Timeout: 5 * time.Second}
for i := 0; i < 50; i++ {
wg.Add(1)
go worker(i, tasks, &wg, client)
}
for i := 0; i < 500; i++ {
tasks <- 'http://127.0.0.1:8080/api'
}
close(tasks)
wg.Wait()
}
上述代码用50个常驻goroutine消费500个任务，避免了无节制派生协程。在实际压测中，我们还会引入rate.Limiter来约束每秒请求数，使得压力曲线平滑。相比单纯依靠线程的Java工具，Go的调度器在上下文切换成本上更低，这也是它适合写压测器的底层原因。
超时、重试与连接复用细节
压测工具如果忽略超时设置，个别慢响应会拖住worker导致整体吞吐失真。http.Client的Timeout字段控制整个请求生命周期，而Transport中的IdleConnTimeout决定空闲连接回收时间。对于短平快的接口压测，建议把IdleConnTimeout设为一两分钟，并开启MaxIdleConnsPerHost提升复用率。
很多初学者在代码里每次请求都新建http.Client，这会让连接无法复用并且丢失连接池优势。正确方式是在所有worker间共享同一个client实例。如果被测服务偶尔返回5xx，是否重试需要谨慎：压测目的是暴露真实容量，盲目重试会掩盖错误率。可以通过计数器记录状态码分布，而不是在工具内自动重发。
transport := &http.Transport{
MaxIdleConns: 1000,
MaxIdleConnsPerHost: 1000,
IdleConnTimeout: 90 * time.Second,
}
client := &http.Client{
Transport: transport,
Timeout: 3 * time.Second,
}
当压测HTTPS服务时，还可以将TLSHandshakeTimeout单独设置，防止握手阶段耗费过多时间影响统计。在长时间跑批中，建议周期性打印已发请求数与错误数，以便观察是否存在连接泄漏。若发现本地文件描述符上涨，应检查resp.Body是否每次都调用了Close。
指标统计与结果输出
一个合格的压测工具不能只打印日志，需要提供量化的QPS、延迟百分位与错误率。我们可以用原子变量记录成功数与失败数，用切片收集每次请求的耗时，最后排序计算P50、P95、P99。由于多goroutine写同一切片需要加锁，更优方案是每个worker维护本地数组，结束后由主线程合并。
延迟分布比平均值更有参考价值。例如平均延迟20毫秒但P99达到800毫秒，说明存在长尾请求。下方代码演示了如何用sync/atomic累计计数，并在退出前做简单排序输出。如果请求量极大，也可采用直方图桶来降低内存占用。
var success int64
var fail int64
func record(err error) {
if err != nil {
atomic.AddInt64(&fail, 1)
} else {
atomic.AddInt64(&success, 1)
}
}
func report() {
s := atomic.LoadInt64(&success)
f := atomic.LoadInt64(&fail)
fmt.Printf('success=%d fail=%d total=%dn', s, f, s+f)
}
最终报告建议包含测试时长、并发数、总请求数、错误率和分位延迟。将这些数据落盘为CSV或直接在终端以表格展示，都能帮助研发判断服务拐点。相比wrk等黑盒工具，自研方案允许你把业务特有的标签如用户等级、地区编码带入请求头，从而模拟更真实的流量结构。