用 go test 模拟并发 HTTP 请求需启动临时服务并用 goroutine 发请求，关键在于避免泄漏与阻塞：设超时、用 WaitGroup 等待、禁用 log.Fatal；读多写少用 RWMutex，高频计数用 atomic；GOMAXPROCS 不宜过高，应结合 pprof 优化；Transport 需调优连接复用参数以匹配后端能力。
如何用 go test 模拟并发 HTTP 请求
Go 自带的 testing 包不直接支持并发压测，但你可以用 go test 启动一个临时 HTTP 服务，再在测试函数里起多个 goroutine 发请求。关键不是“怎么写测试”，而是“别让 goroutine 泄漏或阻塞”。
常见错误是忘记加 time.Sleep 或 sync.WaitGroup，导致测试提前结束、部分请求没发出去；或者用 http.DefaultClient 不设超时，遇到慢响应就卡死整个测试。
- 每个 goroutine 必须用独立的
*http.Client或至少设置Timeout（推荐10 * time.Second） - 用
sync.WaitGroup等待所有请求完成，defer wg.Done()必须在 goroutine 内部调用 - 避免在测试中用
log.Fatal或os.Exit，会中断整个go test流程
sync.Mutex 和 sync.RWMutex 在压测中怎么选
读多写少场景（比如缓存计数器、配置热加载）用 sync.RWMutex 能明显提升吞吐；但如果你只是保护一个简单字段（如 totalRequests int64），直接用 sync/atomic 更轻量、无锁、更安全。
容易踩的坑是：在 HTTP handler 里对同一个 sync.Mutex 加锁时间过长（比如锁住整个 DB 查询+模板渲染），会导致并发数上不去，看起来像“并发失效”。这时锁粒度比锁本身更关键。
- 写操作极少（如每分钟一次配置更新）→ 用
sync.RWMutex，读完全不互斥 - 高频累加/比较（如请求数、错误计数）→ 改用
atomic.AddInt64、atomic.LoadInt64 - 锁内不要调用可能阻塞的函数（
http.Get、time.Sleep、数据库查询）
为什么 runtime.GOMAXPROCS 设太高反而降低性能
默认值是 CPU 核心数，不是越大越好。Goroutine 调度开销、上下文切换、内存竞争都会随 P 数上升而变显著，尤其在 I/O 密集型服务中——你设成 128，实际活跃 goroutine 可能只有几十个，其余都在等网络或锁。
