不能直接用GoLand的“Run with go test -bench”按钮写压力测试脚本，因其仅执行go test -bench=.，只预热、调b.N、报告ns/op和Allocs/op，不支持HTTP请求、连接池管理、错误率统计、持续运行或QPS控制。
不能直接用 GoLand 的“Run with go test -bench”按钮写压力测试脚本——它只会跑 BenchmarkXxx 函数，而这类函数天生不适合模拟真实请求压测。
GoLand 里点“Run Benchmark”本质是执行 go test -bench
GoLand 的绿色三角按钮对 BenchmarkXxx 函数触发的是 go test -bench=.，它只做三件事：预热、自动调整 b.N、报告 ns/op 和 Allocs/op。它不发 HTTP 请求、不管理连接池、不统计错误率、也不支持持续运行或 QPS 控制。
- 你看到的
BenchmarkHTTPGet跑出 “1256234 ns/op”，只是单次http.Get的平均耗时，不是并发能力指标 -
b.RunParallel启的 goroutine 是为消除单次调用开销设计的，没有超时、无失败回调、无法区分 success/timeout/fail - GoLand 默认不会帮你加
b.ResetTimer()或禁用log.Printf，计时容易被初始化代码污染
真要压测，得在 GoLand 里新建 main.go 而不是 *_test.go
GoLand 支持任意 .go 文件右键 Run，这才是写可调试压测脚本的正路。别把压力逻辑塞进 BenchmarkXxx，直接写 main 包，用标准库组合控制节奏和统计：
GoLand 2026.1.1
下载
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
- 用
time.Ticker控制固定 QPS（比如每 10ms 发 1 个请求），比裸起 goroutine 更可控 - 用
sync.WaitGroup等待全部请求结束，用sync/atomic计数成功/失败/超时次数 - 显式配置
http.Transport：设MaxIdleConns和MaxIdleConnsPerHost≥ 2000，否则本地连接池很快耗尽 - GoLand 调试时能直接断点进
resp, err := client.Do(req)，看具体哪一步卡住或返回非 2xx
GoLand 中调试压测脚本最容易忽略的三个资源坑
本地跑着跑着就卡死或报 dial tcp: lookup xxx: no such host？大概率是没管住底层资源，GoLand 不会自动帮你调系统参数：
- DNS 缓存未预热：
http.DefaultTransport.(*http.Transport).DialContext没换，压测中途换 IP 就失败；解决：提前用net.DefaultResolver.LookupHost预热一次 - 本地端口不够用：Linux 默认
net.ipv4.ip_local_port_range是 32768–65535（约 32K 端口），压测超 1.5 万并发前必须手动扩到"1024 65535" - 文件描述符限制：GoLand 终端默认继承 shell 的 ulimit，
ulimit -n查当前值，压测前至少设为 65536，否则too many open files
真正可复现的压力脚本，从来不是靠 GoLand 自动生成的测试模板，而是你亲手写的 main 函数——它不依赖 testing.B 的隐含逻辑，能精确控制每个连接、每次超时、每条日志输出位置。
