go test 不支持高并发压力测试，仅适用于单次隔离的基准或单元验证；真压测需自写 goroutine+waitgroup 脚本或用专用工具，-race 仅辅助查竞态，不能替代压测。
直接说结论：go test 本身不支持高并发压力测试，它只做单次、可控、隔离的基准或单元验证；真要压测高并发函数，得自己写压测逻辑或用专用工具（比如基于 goroutine + sync.WaitGroup 的轻量脚本），-race 只能辅助发现竞态，不能替代压测。
为什么 go test -bench 不算“高并发压力测试”
go test -bench 的本质是单 goroutine 循环调用被测函数 b.N 次，哪怕你加了 -cpu=4，也只是并行运行多个独立的 BenchmarkXxx 函数实例，不是模拟真实请求并发竞争同一资源——它测的是吞吐上限，不是系统在并发冲击下的稳定性、超时、错误率或资源耗尽表现。
- 它不会创建成百上千个 goroutine 同时抢锁、争 channel、打满连接池
- 它不控制请求间隔、不模拟网络抖动、不统计失败重试或熔断行为
-
-benchmem只看单次调用内存分配，看不出高并发下 GC 压力突增或对象逃逸恶化
怎么写一个真正能压测高并发函数的脚本
核心是手动构造并发模型：用 sync.WaitGroup 控制总请求数，用带缓冲的 chan struct{} 或 semaphore 控制并发度，每个 goroutine 独立执行被测函数并记录结果。
- 被测函数必须是线程安全的，否则压测过程会触发
-race报告（见下节） - 别在压测循环里做日志打印或 fmt 输出，这会严重拖慢速度、掩盖真实瓶颈
- 用
time.AfterFunc或单独 goroutine 控制压测总时长，避免依赖固定请求数 - 示例关键片段：
func stressTest(fn func(), concurrency, durationMs int) {
var wg sync.WaitGroup
sem := make(chan struct{}, concurrency)
start := time.Now()
for i := 0; i <h3>go test -race 能帮你发现什么，又不能帮你发现什么</h3><p><code>-race</code> 是竞态检测器，不是压测工具。它只在程序实际执行路径中、且变量访问满足“多 goroutine + 非同步 + 至少一次写”时才报警。</p>
- 它能抓到：共享 map 未加锁读写、全局变量被并发修改、channel 关闭后仍往里 send
- 它抓不到：连接池耗尽导致的 timeout、context deadline 被忽略、锁粒度太粗引发的饥饿、goroutine 泄漏（除非泄漏本身触发写冲突）
- 启用方式很简单：
go test -race或go run -race main.go，但必须真实跑起并发逻辑才会生效——光写 goroutine 不执行，-race不会报 - 注意：
-race会让程序变慢 5–10 倍，内存占用翻倍，仅用于开发/测试环境，绝不能开在生产
容易被忽略的三个实操细节
压测高并发函数时，最常栽在边界条件上：
- 被测函数内部用了
time.Sleep或阻塞 I/O，但没设超时，压测会卡死——务必检查所有外部调用是否带 context 或 deadline - 用
sync.Pool缓存对象时，如果New函数返回 nil 或 panic，压测中会静默失败，需加 recover 包裹 - 并发数设太高（比如 > 10000），而目标函数本身依赖文件描述符或数据库连接池，结果不是压垮函数，而是先耗尽系统资源——建议从 100 开始逐步加压，观察
netstat -an | grep :port | wc -l和ulimit -n
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
