vegeta压测HTTP接口时400暴增主因是未显式设置Content-Type导致服务端拒绝解析请求体；Go SDK需通过Options注入Transport和Timeout来复用客户端配置；p99远高于mean表明长尾延迟严重；CI中须调大ulimit避免资源限制失败。
vegeta 命令行压测 HTTP 接口时，为什么 400 错误暴增但服务端日志没报错？
常见现象是：用 vegeta 发 POST 请求，curl 或 Postman 能正常返回，但压测一跑就大量 400 Bad Request。根本原因往往是请求体格式不匹配——vegeta 默认不自动设 Content-Type，而你的接口依赖该 header 判断 JSON 解析逻辑。
- 必须显式加
-header="Content-Type: application/json"，否则 Go 的http.Request会发空 header，某些框架（如 Gin、Echo）拒绝解析无类型的 JSON body - 如果接口要求
application/x-www-form-urlencoded，也得对应改 header，且用-body传键值对字符串（如"name=foo&age=12"），不能传 JSON 字符串 -
-body文件路径需为绝对路径或相对当前工作目录，vegeta不做路径补全，填错就发空 body，触发 400
用 Go 写 vegeta 自定义攻击器时，如何复用已有 HTTP 客户端配置？
vegeta 的 Go SDK（github.com/tsenart/vegeta/v12）不暴露底层 http.Client 实例，但允许你通过 vegeta.NewAttacker 的 Options 注入自定义 transport 和 timeout，这是唯一可控入口。
- 不要试图替换
http.DefaultClient，vegeta内部不使用它 - 用
vegeta.NewAttacker(vegeta.Timeout(30*time.Second), vegeta.Transport(&http.Transport{...}))来控制连接池、TLS 设置、超时等 - 若需带认证（如 Bearer Token），必须在每个
vegeta.NewTargeter返回的*vegeta.Target中设置Header字段，SDK 不支持全局 header - 注意：自定义
Transport的MaxIdleConnsPerHost建议设为1000以上，否则高并发下连接复用率低，容易触发connection refused
vegeta report 输出的 p99 和 mean 差距过大，说明什么？
当 vegeta report -type=text 显示 p99=2500ms 但 mean=320ms，代表长尾延迟严重——少量请求卡顿拉高了分位数，不是平均性能差。这通常指向后端非均匀瓶颈，比如数据库连接池打满、GC STW、或某类请求触发慢路径。
- 先用
vegeta encode -to=csv导出原始响应时间，用 Excel 或awk看分布：是否集中在某几个时间点突增？对应检查服务端 GC 日志或 DB 慢查询 - 避免只看
rate=100单一并发，改用-cpus=4 -rate=50多线程 + 中等速率组合，更贴近真实流量模式 - Go 服务若启用了
http.Server.ReadTimeout，超时会直接断连，vegeta记为error而非延迟，此时report里errors数量比p99更关键
在 CI 流水线中稳定运行 vegeta，绕不开的权限与资源陷阱
CI 环境（如 GitHub Actions、GitLab Runner）默认限制进程数、文件描述符和内存，vegeta 高并发压测极易触发失败，错误信息常为 too many open files 或 fork/exec: resource temporarily unavailable。
立即学习“go语言免费学习笔记（深入）”；
- Linux 下必须前置执行
ulimit -n 65536，否则默认1024连接数顶多撑住-rate=50 - Docker 容器内运行需加
--ulimit nofile=65536:65536，K8s 则要在securityContext中配fsGroup和ulimits - Go 编译的
vegeta二进制本身无依赖，但若用go run启动 SDK，CI 的 Go 版本需 ≥1.19（v12SDK 要求），否则编译失败静默退出
真实压测里最麻烦的从来不是命令写对没，而是服务端日志里那个没打出来的 panic，和 CI 机器上没人改过的 ulimit。
