Vegeta压测大量400错误主因是未显式设置Content-Type请求头或-body路径错误：其默认不发该头，导致Gin/Echo等框架解析失败直接返回400；-body后路径须为绝对路径或相对当前工作目录，否则发空body被拒。
Vegeta 压测时大量 400 错误，基本就是没设 Content-Type 或 -body 路径错了——服务端不认空 header 或空 body，直接拒掉。
vegeta POST 请求为什么总返回 400？
现象：curl 或 Postman 能通，vegeta 一压就满屏 400 Bad Request，但服务端日志里没报错、也没解析失败记录。
根本原因不是接口逻辑问题，而是 vegeta 默认不发 Content-Type header。Gin/Echo/HTTP 标准库等都会检查这个字段：没它，json.Decode 直接跳过、返回 400；若接口要 application/x-www-form-urlencoded，也得手动配对。
- 必须显式加
-header="Content-Type: application/json"（或对应类型） -
-body后跟的路径必须是绝对路径，或相对于当前 shell 工作目录——vegeta 不做路径补全，填错就发空 body - 如果用 targets 文件写 POST，格式必须严格：
POST http://x/y换行后接@body.json，不能漏换行或写错符号
vegeta report 里 p99 远高于 mean 怎么看？
p99=2500ms 但 mean=320ms，说明不是整体慢，而是少数请求卡死。这不是“平均性能差”，是长尾延迟严重。
立即学习“go语言免费学习笔记（深入）”；
典型诱因包括：DB 连接池耗尽、GC STW 时间突增、某类请求触发慢查询或锁竞争、或 http.Server.ReadTimeout 触发后被 vegeta 记为 error 而非延迟（此时看 errors 数比 p99 更关键）。
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 先用
vegeta encode -to=csv results.bin > raw.csv导出原始响应时间，用 awk 或 Excel 看分布是否集中在某几个时间点突起 - 避免只跑
-rate=100单一线程，改用-cpus=4 -rate=50多线程 + 中等速率，更贴近真实流量压力模式 - 确认服务端是否启用了
ReadTimeout/WriteTimeout，这类超时会断连，vegeta 统计为error，不在延迟分布里
Go SDK 里怎么复用已有 HTTP 客户端配置？
vegeta 的 Go SDK（github.com/tsenart/vegeta/v12）不暴露 http.Client，也不能改 http.DefaultClient——它内部完全不走那个实例。
唯一可控入口是 vegeta.NewAttacker 的 Options：
- 用
vegeta.Timeout(30*time.Second)控制单请求超时 - 用
vegeta.Transport(&http.Transport{MaxIdleConnsPerHost: 1000})配连接池；不设高点（比如1000），高并发下连接复用率低，容易报connection refused - 全局 header 不支持；每个
vegeta.Target必须自己填Header字段，比如带 Bearer Token
CI 环境里 vegeta 压测失败但本地能过？
常见于资源限制：CI runner 默认 ulimit -n 很低（常为 1024），vegeta 高并发时快速耗尽文件描述符，报 too many open files 或连接失败。
这不是 vegeta bug，是系统级限制没调。
- 在 CI 脚本开头加
ulimit -n 65536（需 runner 允许） - 压测命令里加
-connections=1000显式控住每 host 最大空闲连接数，别依赖默认的 10000 - 避免在 CI 里用
-rate过高（如 500+）且-duration过短（如 1s），短时脉冲容易触发内核限流
Vegeta 本身很轻，但它的并发行为会把底层 OS 限制和后端服务的非线性瓶颈全暴露出来——真正难调的从来不是 vegeta 命令，而是你没意识到的那层隐式约束。
