编写贴近真实的负载测试场景

用 k6 建模到达速率、爬坡与思考时间，断言 p95 延迟与错误率阈值，并在发布前对预发环境执行。

概述

一个接一个发请求的压测只模拟了没有思考时间的单个用户，既不体现并发，也不体现真实到达速率。真实流量按速率到达，用户阅读时保持连接，并访问大量不同记录。服务在每秒 10 个请求时看似健康，到每秒 200 个请求却可能崩溃，因为连接池、锁或缓存键的退化是非线性的。场景必须复现流量的形状，而不只是接口清单。

步骤

使用 ramping-arrival-rate 直接表达“每秒 200 个请求”，并设置爬坡、平台期与下降阶段。
脚本化用户旅程：先列表、再详情，并在步骤之间加入 1 到 3 秒随机思考时间。
用 SharedArray 载入数千个真实 id，让工作集超过内存缓存。
阈值取自 SLO 而不是上次运行结果：

thresholds: {
  http_req_duration: ['p(95)<300', 'p(99)<800'],
  http_req_failed: ['rate<0.01'],
},

用 --summary-export 保存结果，并与上一个版本的同一指标对比。

验证

平台期应稳定在每秒 200 个请求，p95 约 210 毫秒、p99 约 540 毫秒、错误率低于 0.5%。若 dropped_iterations 大于 0，说明压测机本身成为瓶颈。把本次 p95 与上次对比，7% 的退化即使仍在阈值内也应记录并评估。

注意事项

预发环境容量通常小于生产，结果只具有相对意义，必须固定在同一环境对比。
综合事务无法覆盖所有真实路径与第三方延迟，关键链路需要单独场景。
压测会写入数据并消耗配额，应隔离环境并在结束后重置。
冷缓存会让第一分钟指标失真，应增加不计入阈值的预热阶段。
恒定 VU 执行器会让响应变慢时实际流量下降，容量问题应使用到达速率执行器。