k6 JavaScript 性能压测 CLI

它解决什么问题

接口改动之后，/login 在 1 个并发和 500 个并发下的 P99 延迟往往完全是两个数，但多数 CI 流水线跑通冒烟测试就放行了。等到预发环境拿一次性压测工具试一次，脚本散落在个人电脑上，参数不可复现，回归时也说不清是哪次改动把尾延迟抬高了 300ms。这个技能要解决的，就是把负载场景变成仓库里可版本化、可在 CI 中重复执行的性能检查。

它如何工作

• 用 JavaScript 编写测试脚本，虚拟用户、阶梯加压、阈值判定这些逻辑全部落在代码里，可以被 diff、review 和回滚
• 同一份脚本能走三条执行路径：本地 CLI、CI job、Kubernetes 集群，环境差异靠参数和配置注入，不需要重写脚本
• 依赖 Go 编写的 k6 与 JavaScript 运行时，不需要浏览器驱动或额外的测试框架
• 执行结果可以接入可观测性流程，和监控面板上的真实指标对照排查

关键步骤：编写脚本 → 本地跑通 → 提交到 CI 作为门禁 → 在集群里按接近真实的规模加压 → 对照阈值定位瓶颈。

边界与注意点

• 脚本覆盖的是合成负载，不等于真实用户流量分布，地域来源、缓存命中率、慢请求尾部这些仍需结合线上观测数据判断
• k6 是压测客户端，不替代服务端 profiling 和链路追踪，CPU 热点和锁竞争还得靠 profiler 去挖
• 在集群里执行时要控制并发实例与连接数，否则压测端自己先成为瓶颈
• 高并发场景下要权衡 VU 数和迭代次数，阶梯模型比固定并发更容易暴露性能拐点