用途：用于在发布前、基础设施变更后或大促扩容前规划并执行性能测试，验证系统在预期与超预期流量下的表现，并定位影响用户体验的瓶颈。
主要能力：
- 明确 SLO，例如 p95 响应时间 < 200ms、错误率 < 0.1%、吞吐 10k req/min、CPU < 70%、内存 < 80%。
- 按目标选择测试类型：负载测试验证预期流量，压力测试寻找崩溃点，峰值测试应对突发流量，耐久/浸泡测试发现内存泄漏与资源耗尽，扩展性测试验证水平或垂直扩容。
- 构造贴近真实用户旅程的分布式场景，包含思考时间（如 sleep 1-5 秒）与混合行为比例，而非让所有用户重复访问首页。
- 执行时同步监控 CPU、内存、数据库查询与网络，并分析结果。
常见瓶颈与处理：数据库慢查询、连接池耗尽（加索引、优化 N+1、增大连接池、只读副本）；请求路径中的同步阻塞（改用消息队列异步处理）；内存泄漏（耐久测试与内存分析，检查未清理的事件监听器、无淘汰策略的缓存）；外部依赖（超时、熔断、缓存、优雅降级）。
工具与用法：k6（现代、基于 JS、适合 CI/CD）、JMeter、Artillery、Gatling。k6 中用 stages 配置爬坡、稳态、回落，thresholds 定义 p(95)<200 与 rate<0.01；可通过 grafana/k6-action 集成到 GitHub Actions。
限制与注意事项：资料未提供具体价格、平台支持范围或性能承诺；避免测试过晚、场景不真实、瞬间从 0 加到 1000 用户、测试期间无监控、缺少基线或只做一次性测试。测试频率建议：负载每次发布，压力每季度，峰值在活动前，耐久在代码变更后，扩展性在基础设施变更时。