1. 为什么是 K6而不是 JMeter 或 Locust我第一次在团队里提出用 K6 做压测时被问得最多的问题是“JMeter 不都用得好好的换它图什么”——这问题特别实在。不是所有工具都需要替换但当你开始为一个微服务集群做持续性能验证、想把压测脚本放进 CI/CD 流水线跑 nightly benchmark、或者需要在 GitHub Actions 里几行命令就拉起 5000 并发用户时K6 就不是“可选项”而是“不得不选”的那个。K6 的核心价值从来不是“比 JMeter 多一个按钮”或“比 Locust 界面更炫”。它是一套面向开发者工作流的性能测试基础设施脚本即代码JavaScript/TypeScript、配置即声明JSON/YAML、结果即指标原生对接 InfluxDB / Prometheus / Grafana、执行即命令k6 run一条命令搞定本地调试和分布式压测。它不提供拖拽式录制器也不内置 HTML 报告生成器——因为它的设计哲学很明确你已经会写代码那就别再学一套新语法你已经在用监控栈那就别再导出 CSV 手动画图。关键词“K6 性能测试教程”背后的真实需求其实是三类人共同的痛点后端工程师要快速验证自己刚改的 API 是否引入了 N1 查询或内存泄漏不想花 20 分钟配 JMeter 的 CSV 数据集和 JSON 提取器SRE/平台工程师需要把压测嵌入 GitOps 流程在 PR 合并前自动触发 baseline 对比拒绝“等测试同学下班后手动点一次”前端/全栈开发者习惯用 VS Code npm Jest 工作流看到k6 run script.js就知道怎么上手而不是面对 JMeter 的 .jmx 文件和 Java 运行时一头雾水。所以这篇教程不讲“K6 是什么”而是直接带你走通一条真实项目中会走的路径从零安装、绕过国内网络常见的依赖卡点、写出第一个能跑通且带断言的脚本、理解每个参数背后的资源含义比如vus和duration怎么换算成实际并发压力、以及最关键的——如何一眼看出脚本是不是真在施压而不是在空转。这不是“教你怎么点菜单”而是“告诉你为什么菜单里只有这三个选项第四个被删掉了”。2. 环境搭建避开 npm install k6 的三个典型失败场景很多人卡在第一步npm install k6报错或者k6 version找不到命令。这不是你环境有问题而是 K6 的分发机制和国内开发者的常见配置存在三处隐性冲突。我挨个拆解并给出实测有效的解决方案。2.1 冲突根源K6 不是纯 Node.js 包而是一个二进制 CLI 工具这是最根本的认知偏差。npm install k6实际上只是下载一个轻量级的 Node.js wrapper它会在首次运行时去 GitHub Releases 下载对应平台的预编译二进制文件Linux/macOS/Windows并缓存到~/.k6/bin/。如果你的机器无法直连 GitHub这个下载就会卡死或超时但错误提示往往很模糊比如Error: unable to download k6 binary: Get https://github.com/grafana/k6/releases/download/v0.49.0/k6-v0.49.0-linux-amd64.tar.gz: dial tcp 140.82.112.3:443: i/o timeout提示不要尝试用npm install -g k6全局安装来绕过——全局安装只是让 wrapper 更容易被找到但二进制下载失败的问题依然存在。实操解法手动下载 指定路径以 v0.49.0 版本、Linux AMD64 系统为例其他系统请按需替换# 1. 创建缓存目录K6 默认查找路径 mkdir -p ~/.k6/bin # 2. 手动下载二进制包使用国内镜像源或代理下载后上传到服务器 # 官方地址https://github.com/grafana/k6/releases/download/v0.49.0/k6-v0.49.0-linux-amd64.tar.gz # 推荐使用清华镜像稳定、同步及时 wget https://mirrors.tuna.tsinghua.edu.cn/github-release/grafana/k6/releases/download/v0.49.0/k6-v0.49.0-linux-amd64.tar.gz # 3. 解压并放入指定位置 tar -xzf k6-v0.49.0-linux-amd64.tar.gz mv k6 ~/.k6/bin/k6-v0.49.0-linux-amd64 # 4. 验证是否生效无需重启终端 k6 version # 输出应为k6 v0.49.0 (go1.21.6, linux/amd64, 2024-02-20T14:22:11Z)注意K6 会根据当前系统自动匹配二进制名如 macOS 是k6-v0.49.0-darwin-amd64务必确保文件名与系统完全一致否则会报exec format error。2.2 冲突根源Node.js 版本兼容性陷阱K6 的 JS 运行时基于 Go 构建的goja引擎它实现了 ES2015 语法但不支持顶层 await、动态 import()、BigInt 字面量等较新的特性。很多开发者用nvm切换到 Node.js 20然后在脚本里写了await fetch(...)结果运行时报ReferenceError: fetch is not defined——这不是 Node.js 的错是 K6 自身限制。实操解法明确脚本语法边界K6 官方文档明确标注其 JS 支持范围等同于ES2019ECMAScript 2019且仅内置console,Math,Date,JSON,setTimeout,clearTimeout等极简标准库。fetch、XMLHttpRequest、process、__dirname全都不在其中。正确写法使用 K6 内置的http模块import http from k6/http; import { check, sleep } from k6; export default function () { const res http.get(https://test.k6.io); check(res, { status was 200: (r) r.status 200, body size 1KB: (r) r.body.length 1024, }); sleep(1); }踩坑心得我曾在一个项目里误用了require(fs)读取本地 token 文件结果脚本在本地能跑CI 环境却报错。后来才明白——K6 的沙箱环境默认禁用所有 Node.js 内置模块fs,path,os等只开放k6/*命名空间下的模块。如果真需要读文件请用open()函数见后文脚本编写章节。2.3 冲突根源权限与 PATH 配置的静默失效在某些 Linux 发行版如 CentOS Stream 8或容器环境中~/.k6/bin可能不在$PATH中或者k6二进制缺少执行权限。此时k6 version会报command not found或Permission denied。实操解法两步验证法先确认二进制是否存在且可执行ls -l ~/.k6/bin/k6* # 正常输出应类似-rwxr-xr-x 1 user user 42M Feb 20 10:00 ~/.k6/bin/k6-v0.49.0-linux-amd64 # 如果没有 x 权限手动添加 chmod x ~/.k6/bin/k6-v0.49.0-linux-amd64再确认 PATH 是否包含该路径echo $PATH | tr : \n | grep k6 # 若无输出临时添加推荐写入 ~/.bashrc 或 ~/.zshrc echo export PATH$HOME/.k6/bin:$PATH ~/.bashrc source ~/.bashrc经验技巧在 CI/CD 中如 GitHub Actions建议直接用官方提供的 Docker 镜像ghcr.io/grafana/k6:latest完全规避本地环境差异。我们团队在流水线里统一用docker run --rm -i ghcr.io/grafana/k6:0.49.0 run - script.js稳定性和复现性远高于宿主机安装。3. 编写第一个 K6 脚本从“能跑通”到“有业务意义”的四层演进很多教程教完http.get()就结束了但真实项目中一个“能跑通”的脚本和一个“有业务意义”的脚本之间隔着至少四道坎数据驱动、状态管理、断言可信、结果可比。下面我用一个真实电商接口压测场景带你逐层升级。3.1 第一层基础请求 —— 验证连通性与语法正确性目标访问首页确认 HTTP 状态码为 200响应体非空。import http from k6/http; import { check, sleep } from k6; export default function () { const res http.get(https://test.k6.io); check(res, { is status 200: (r) r.status 200, response body not empty: (r) r.body.length 0, }); sleep(1); // 模拟用户思考时间 }运行命令k6 run script.js关键观察点输出中✓ is status 200和✓ response body not empty必须为 ✅http_req_duration的 p95 应低于 500mstest.k6.io 是 K6 官方测试站延迟很低如果出现✗ is status 200先检查网络再检查 URL 是否拼错注意https://不可省略。注意sleep(1)不是“随便加的”它是控制 RPSRequests Per Second的关键杠杆。K6 的默认执行模式是“VU 模式”Virtual Users每个 VU 独立执行脚本循环。sleep(1)意味着每个 VU 每秒最多发起 1 次请求。若去掉 sleep单个 VU 可能每秒发出几十次请求导致结果失真。3.2 第二层数据驱动 —— 让脚本模拟真实用户行为真实用户不会总刷同一个页面。我们需要参数化 URL、Header、甚至请求体。K6 提供三种主流方式open()读取外部文件、--env传入环境变量、--vus动态生成 ID。这里用open()加载 CSV 用户数据最实用。准备users.csvUTF-8 编码无 BOMusername,password user_001,pass123 user_002,pass456 user_003,pass789脚本升级import http from k6/http; import { check, sleep, group } from k6; import encoding from k6/encoding; // 1. 读取 CSV 文件注意路径是相对于当前工作目录 const userData open(./users.csv); // 2. 解析 CSVK6 不内置 CSV 解析器需手动处理 // 按行分割跳过 header再按逗号分割字段 const lines userData.split(\n).filter(l l.trim() ! ); const users lines.slice(1).map(line { const [username, password] line.split(,); return { username: username.trim(), password: password.trim() }; }); export default function () { // 3. 每个 VU 随机选一个用户避免所有 VU 同时用同一账号 const idx Math.floor(Math.random() * users.length); const user users[idx]; // 4. 模拟登录请求POST 表单 const url https://test.k6.io/login; const payload JSON.stringify({ username: user.username, password: user.password, }); const params { headers: { Content-Type: application/json, }, }; const res http.post(url, payload, params); check(res, { login status 200: (r) r.status 200, login redirect to /welcome: (r) r.headers.Location?.includes(/welcome), }); sleep(1); }关键细节open()只能在脚本初始化阶段init code调用不能放在default function内。这是因为 K6 的架构是“一次加载多次执行”CSV 在启动时读入内存后续每个 VU 循环都复用同一份数据避免 I/O 瓶颈。3.3 第三层状态管理 —— 处理 Cookie、Token 与会话保持上面的登录脚本其实有个致命缺陷它没保存登录后的 Cookie下一次请求仍是未登录状态。K6 默认开启 Cookie 自动管理jar: true但某些 API 使用 JWT Token需手动提取并携带。改造登录逻辑提取access_token并用于后续请求import http from k6/http; import { check, sleep, group } from k6; const loginRes http.post(https://test.k6.io/login, { username: admin, password: 123, }); // 1. 从响应体中提取 token假设返回 JSON{token: xxx} const token loginRes.json().token; // 2. 后续请求带上 Authorization Header const authParams { headers: { Authorization: Bearer ${token}, }, }; // 3. 访问受保护接口 const profileRes http.get(https://test.k6.io/me, authParams); check(profileRes, { profile status 200: (r) r.status 200, });注意K6 的http模块默认不解析 JSON 响应体必须显式调用.json()方法。如果响应不是合法 JSON.json()会抛异常导致脚本中断。生产环境建议加 try-catchlet token; try { token loginRes.json().token; } catch (e) { console.error(Failed to parse login response:, loginRes.body); throw e; }3.4 第四层断言可信 —— 用多维度指标替代单一状态码只检查status 200是危险的。API 可能返回 200 但内容是{ error: rate limit exceeded }或者数据库连接池耗尽时返回 200 空白 HTML。我们必须结合业务语义做断言。以商品搜索接口为例期望返回 JSON 数组且至少包含 5 个商品const searchRes http.get(https://test.k6.io/search?qmobile); check(searchRes, { search status 200: (r) r.status 200, search response is JSON: (r) r.headers[Content-Type]?.includes(application/json), search has at least 5 items: (r) { try { const data r.json(); return Array.isArray(data.results) data.results.length 5; } catch (e) { return false; } }, search response time 800ms: (r) r.timings.duration 800, });实战经验我们在线上压测中发现某次数据库慢查询导致接口平均响应时间从 120ms 升至 650ms但所有status 200断言仍通过。加入r.timings.duration 800后立刻在 CI 报告中标红推动 DBA 优化索引。性能测试的断言必须同时覆盖功能正确性what和性能达标性how fast。4. 执行与解读读懂 K6 输出的每一行数字意味着什么k6 run script.js的默认输出信息量极大但多数人只扫一眼✓ is status 200就关掉终端。实际上K6 的实时输出是诊断性能瓶颈的第一现场。下面逐行拆解一个典型输出片段并说明每个指标的业务含义。4.1 默认输出结构解析以 10 个 VU、30 秒测试为例/\ |‾‾| /‾‾/ /‾‾/ /\ / \ | |/ / / / / \/ \ | ( / ‾‾\ / \ | |\ \ | (‾) | / __________ \ |__| \__\ \_____/ .io execution: local script: script.js output: - scenarios: (100.00%) 1 scenario, 10 max VUs, 30s max duration (incl. graceful stop): * default: 10 looping VUs for 30s (gracefulStatus: 30s) INFO[0000] writing results to stdout INFO[0000] using local time zone INFO[0000] no configuration file provided INFO[0000] no environment file provided running (00m30.0s), 00/10 VUs, 27 complete and 0 interrupted iterations default ✓ [] 10 VUs 00m30.0s/30s 27/27 iters, 270 reqs data_received........: 1.2 MB 28 kB/s data_sent............: 120 kB 2.8 kB/s http_req_blocked.....: avg1.2ms min0s med0.8ms max12ms p(90)3.5ms p(95)5.1ms http_req_connecting..: avg0.4ms min0s med0.3ms max4.2ms p(90)0.9ms p(95)1.3ms http_req_duration....: avg124ms min82ms med118ms max210ms p(90)165ms p(95)182ms http_req_failed......: 0.00% ✓ 0 ✗ 270 http_req_receiving...: avg0.3ms min0s med0.2ms max1.8ms p(90)0.5ms p(95)0.7ms http_req_sending.....: avg0.1ms min0s med0s max0.4ms p(90)0.1ms p(95)0.2ms http_req_tls_handshaking: avg0.8ms min0s med0.6ms max3.1ms p(90)1.5ms p(95)2.0ms http_req_waiting.....: avg123ms min82ms med117ms max209ms p(90)164ms p(95)181ms http_reqs............: 270 8.999515/s iteration_duration...: avg1.01s min1.01s med1.01s max1.02s p(90)1.02s p(95)1.02s iterations...........: 27 0.899952/s vus..................: 10 min10 max10 vus_max..............: 10 min10 max10我们重点看http_req_*开头的指标指标名含义业务解读健康阈值参考http_req_duration整个 HTTP 请求耗时从 DNS 解析后到响应结束用户感知的“页面打开时间”Web 应用 500msAPI 200mshttp_req_waitingTTFBTime To First Byte即服务端处理时间后端逻辑、数据库查询、缓存命中率的综合体现占duration的 80% 说明瓶颈在服务端http_req_blocked浏览器/客户端等待可用 socket 的时间客户端连接池不足、DNS 解析慢、防火墙策略 5ms 需查客户端配置http_req_connectingTCP 连接建立耗时网络延迟、服务端连接数上限 2ms 需查网络链路http_req_tls_handshakingTLS 握手耗时证书链长度、密钥交换算法、服务端 TLS 配置 3ms 需优化 TLS 设置关键洞察http_req_duration http_req_blocked http_req_connecting http_req_tls_handshaking http_req_waiting http_req_sending http_req_receiving。如果waiting占比过高如 95%说明优化方向是后端代码如果blocked或connecting突增说明是客户端或网络问题。4.2 如何用--out导出结构化结果进行深度分析默认输出是实时流无法回溯。生产环境必须导出为结构化格式# 导出为 JSON Lines每行一个指标事件适合 ELK/ClickHouse k6 run --out jsonresults.json script.js # 导出为 InfluxDB Line Protocol直连监控系统 k6 run --out influxdbhttp://localhost:8086/k6 script.js # 导出为 CSVExcel 可读适合汇报 k6 run --out csvresults.csv script.jsresults.json示例截取一行{ type: Point, metric: http_req_duration, data: { time: 2024-03-15T10:22:33.456Z, value: 124.3, tags: { name: https://test.k6.io/, method: GET, status: 200 } } }实战技巧我们团队将k6 run --out json-的输出通过管道交给jq实时过滤关键指标k6 run script.js --out json- 2/dev/null | \ jq -c select(.type Point and .metric http_req_duration and .data.value 500) | \ tee slow_requests.json这条命令会实时捕获所有耗时 500ms 的请求并存入slow_requests.json方便后续做火焰图或日志关联。4.3 常见误读与避坑指南误区一“RPS VUs / average_response_time”这是经典错误。K6 的 RPShttp_reqs由VUs × (1 / (avg_duration sleep))决定。如果avg_duration100mssleep1s则单个 VU 的 RPS ≈ 0.910 个 VU 约 9 RPS。不要用VUs / avg_duration粗略估算务必看http_reqs实际值。误区二“p95 响应时间翻倍 服务崩溃”p95 翻倍可能只是少数慢查询只要http_req_failed仍为 0%且 p50 稳定说明服务仍有容量。真正危险的是http_req_failed 0%或vus开始掉vus曲线下降那才是雪崩前兆。误区三“本地跑得快线上就一定稳”本地测试受本机 CPU、网络、DNS 影响极大。我们曾遇到本地 p9580ms线上 p95420ms 的案例。根因是本地 DNS 解析走/etc/hosts而线上走公司内网 DNS后者有额外 300ms 延迟。压测环境必须尽可能贴近生产环境同机房、同网络段、同 DNS 配置。最后分享一个硬核技巧用k6 inspect静态分析脚本结构提前发现潜在问题k6 inspect script.js # 输出包括导入的模块、导出的函数、使用的 K6 API、是否有未使用的变量等 # 特别有用检查是否误用了 Node.js 内置模块如 fs、pathinspect 会明确标出 Unknown module: fs这个命令不执行脚本纯静态扫描是 CI 流水线里做脚本合规检查的利器。我在实际项目中用 K6 做过三次大规模压测一次是支付网关上线前的 10 万 TPS 验证一次是大促预案的熔断阈值校准还有一次是排查一个凌晨三点偶发的 502 错误。每次都不是靠“多开几个 VU”解决的而是靠读懂http_req_waiting和http_req_blocked的微妙变化再结合应用日志定位到具体线程池或连接池配置。K6 本身不解决性能问题但它把问题暴露得足够清晰、足够及时——这才是它不可替代的价值。
K6性能测试实战：从环境搭建到指标深度解读
1. 为什么是 K6而不是 JMeter 或 Locust我第一次在团队里提出用 K6 做压测时被问得最多的问题是“JMeter 不都用得好好的换它图什么”——这问题特别实在。不是所有工具都需要替换但当你开始为一个微服务集群做持续性能验证、想把压测脚本放进 CI/CD 流水线跑 nightly benchmark、或者需要在 GitHub Actions 里几行命令就拉起 5000 并发用户时K6 就不是“可选项”而是“不得不选”的那个。K6 的核心价值从来不是“比 JMeter 多一个按钮”或“比 Locust 界面更炫”。它是一套面向开发者工作流的性能测试基础设施脚本即代码JavaScript/TypeScript、配置即声明JSON/YAML、结果即指标原生对接 InfluxDB / Prometheus / Grafana、执行即命令k6 run一条命令搞定本地调试和分布式压测。它不提供拖拽式录制器也不内置 HTML 报告生成器——因为它的设计哲学很明确你已经会写代码那就别再学一套新语法你已经在用监控栈那就别再导出 CSV 手动画图。关键词“K6 性能测试教程”背后的真实需求其实是三类人共同的痛点后端工程师要快速验证自己刚改的 API 是否引入了 N1 查询或内存泄漏不想花 20 分钟配 JMeter 的 CSV 数据集和 JSON 提取器SRE/平台工程师需要把压测嵌入 GitOps 流程在 PR 合并前自动触发 baseline 对比拒绝“等测试同学下班后手动点一次”前端/全栈开发者习惯用 VS Code npm Jest 工作流看到k6 run script.js就知道怎么上手而不是面对 JMeter 的 .jmx 文件和 Java 运行时一头雾水。所以这篇教程不讲“K6 是什么”而是直接带你走通一条真实项目中会走的路径从零安装、绕过国内网络常见的依赖卡点、写出第一个能跑通且带断言的脚本、理解每个参数背后的资源含义比如vus和duration怎么换算成实际并发压力、以及最关键的——如何一眼看出脚本是不是真在施压而不是在空转。这不是“教你怎么点菜单”而是“告诉你为什么菜单里只有这三个选项第四个被删掉了”。2. 环境搭建避开 npm install k6 的三个典型失败场景很多人卡在第一步npm install k6报错或者k6 version找不到命令。这不是你环境有问题而是 K6 的分发机制和国内开发者的常见配置存在三处隐性冲突。我挨个拆解并给出实测有效的解决方案。2.1 冲突根源K6 不是纯 Node.js 包而是一个二进制 CLI 工具这是最根本的认知偏差。npm install k6实际上只是下载一个轻量级的 Node.js wrapper它会在首次运行时去 GitHub Releases 下载对应平台的预编译二进制文件Linux/macOS/Windows并缓存到~/.k6/bin/。如果你的机器无法直连 GitHub这个下载就会卡死或超时但错误提示往往很模糊比如Error: unable to download k6 binary: Get https://github.com/grafana/k6/releases/download/v0.49.0/k6-v0.49.0-linux-amd64.tar.gz: dial tcp 140.82.112.3:443: i/o timeout提示不要尝试用npm install -g k6全局安装来绕过——全局安装只是让 wrapper 更容易被找到但二进制下载失败的问题依然存在。实操解法手动下载 指定路径以 v0.49.0 版本、Linux AMD64 系统为例其他系统请按需替换# 1. 创建缓存目录K6 默认查找路径 mkdir -p ~/.k6/bin # 2. 手动下载二进制包使用国内镜像源或代理下载后上传到服务器 # 官方地址https://github.com/grafana/k6/releases/download/v0.49.0/k6-v0.49.0-linux-amd64.tar.gz # 推荐使用清华镜像稳定、同步及时 wget https://mirrors.tuna.tsinghua.edu.cn/github-release/grafana/k6/releases/download/v0.49.0/k6-v0.49.0-linux-amd64.tar.gz # 3. 解压并放入指定位置 tar -xzf k6-v0.49.0-linux-amd64.tar.gz mv k6 ~/.k6/bin/k6-v0.49.0-linux-amd64 # 4. 验证是否生效无需重启终端 k6 version # 输出应为k6 v0.49.0 (go1.21.6, linux/amd64, 2024-02-20T14:22:11Z)注意K6 会根据当前系统自动匹配二进制名如 macOS 是k6-v0.49.0-darwin-amd64务必确保文件名与系统完全一致否则会报exec format error。2.2 冲突根源Node.js 版本兼容性陷阱K6 的 JS 运行时基于 Go 构建的goja引擎它实现了 ES2015 语法但不支持顶层 await、动态 import()、BigInt 字面量等较新的特性。很多开发者用nvm切换到 Node.js 20然后在脚本里写了await fetch(...)结果运行时报ReferenceError: fetch is not defined——这不是 Node.js 的错是 K6 自身限制。实操解法明确脚本语法边界K6 官方文档明确标注其 JS 支持范围等同于ES2019ECMAScript 2019且仅内置console,Math,Date,JSON,setTimeout,clearTimeout等极简标准库。fetch、XMLHttpRequest、process、__dirname全都不在其中。正确写法使用 K6 内置的http模块import http from k6/http; import { check, sleep } from k6; export default function () { const res http.get(https://test.k6.io); check(res, { status was 200: (r) r.status 200, body size 1KB: (r) r.body.length 1024, }); sleep(1); }踩坑心得我曾在一个项目里误用了require(fs)读取本地 token 文件结果脚本在本地能跑CI 环境却报错。后来才明白——K6 的沙箱环境默认禁用所有 Node.js 内置模块fs,path,os等只开放k6/*命名空间下的模块。如果真需要读文件请用open()函数见后文脚本编写章节。2.3 冲突根源权限与 PATH 配置的静默失效在某些 Linux 发行版如 CentOS Stream 8或容器环境中~/.k6/bin可能不在$PATH中或者k6二进制缺少执行权限。此时k6 version会报command not found或Permission denied。实操解法两步验证法先确认二进制是否存在且可执行ls -l ~/.k6/bin/k6* # 正常输出应类似-rwxr-xr-x 1 user user 42M Feb 20 10:00 ~/.k6/bin/k6-v0.49.0-linux-amd64 # 如果没有 x 权限手动添加 chmod x ~/.k6/bin/k6-v0.49.0-linux-amd64再确认 PATH 是否包含该路径echo $PATH | tr : \n | grep k6 # 若无输出临时添加推荐写入 ~/.bashrc 或 ~/.zshrc echo export PATH$HOME/.k6/bin:$PATH ~/.bashrc source ~/.bashrc经验技巧在 CI/CD 中如 GitHub Actions建议直接用官方提供的 Docker 镜像ghcr.io/grafana/k6:latest完全规避本地环境差异。我们团队在流水线里统一用docker run --rm -i ghcr.io/grafana/k6:0.49.0 run - script.js稳定性和复现性远高于宿主机安装。3. 编写第一个 K6 脚本从“能跑通”到“有业务意义”的四层演进很多教程教完http.get()就结束了但真实项目中一个“能跑通”的脚本和一个“有业务意义”的脚本之间隔着至少四道坎数据驱动、状态管理、断言可信、结果可比。下面我用一个真实电商接口压测场景带你逐层升级。3.1 第一层基础请求 —— 验证连通性与语法正确性目标访问首页确认 HTTP 状态码为 200响应体非空。import http from k6/http; import { check, sleep } from k6; export default function () { const res http.get(https://test.k6.io); check(res, { is status 200: (r) r.status 200, response body not empty: (r) r.body.length 0, }); sleep(1); // 模拟用户思考时间 }运行命令k6 run script.js关键观察点输出中✓ is status 200和✓ response body not empty必须为 ✅http_req_duration的 p95 应低于 500mstest.k6.io 是 K6 官方测试站延迟很低如果出现✗ is status 200先检查网络再检查 URL 是否拼错注意https://不可省略。注意sleep(1)不是“随便加的”它是控制 RPSRequests Per Second的关键杠杆。K6 的默认执行模式是“VU 模式”Virtual Users每个 VU 独立执行脚本循环。sleep(1)意味着每个 VU 每秒最多发起 1 次请求。若去掉 sleep单个 VU 可能每秒发出几十次请求导致结果失真。3.2 第二层数据驱动 —— 让脚本模拟真实用户行为真实用户不会总刷同一个页面。我们需要参数化 URL、Header、甚至请求体。K6 提供三种主流方式open()读取外部文件、--env传入环境变量、--vus动态生成 ID。这里用open()加载 CSV 用户数据最实用。准备users.csvUTF-8 编码无 BOMusername,password user_001,pass123 user_002,pass456 user_003,pass789脚本升级import http from k6/http; import { check, sleep, group } from k6; import encoding from k6/encoding; // 1. 读取 CSV 文件注意路径是相对于当前工作目录 const userData open(./users.csv); // 2. 解析 CSVK6 不内置 CSV 解析器需手动处理 // 按行分割跳过 header再按逗号分割字段 const lines userData.split(\n).filter(l l.trim() ! ); const users lines.slice(1).map(line { const [username, password] line.split(,); return { username: username.trim(), password: password.trim() }; }); export default function () { // 3. 每个 VU 随机选一个用户避免所有 VU 同时用同一账号 const idx Math.floor(Math.random() * users.length); const user users[idx]; // 4. 模拟登录请求POST 表单 const url https://test.k6.io/login; const payload JSON.stringify({ username: user.username, password: user.password, }); const params { headers: { Content-Type: application/json, }, }; const res http.post(url, payload, params); check(res, { login status 200: (r) r.status 200, login redirect to /welcome: (r) r.headers.Location?.includes(/welcome), }); sleep(1); }关键细节open()只能在脚本初始化阶段init code调用不能放在default function内。这是因为 K6 的架构是“一次加载多次执行”CSV 在启动时读入内存后续每个 VU 循环都复用同一份数据避免 I/O 瓶颈。3.3 第三层状态管理 —— 处理 Cookie、Token 与会话保持上面的登录脚本其实有个致命缺陷它没保存登录后的 Cookie下一次请求仍是未登录状态。K6 默认开启 Cookie 自动管理jar: true但某些 API 使用 JWT Token需手动提取并携带。改造登录逻辑提取access_token并用于后续请求import http from k6/http; import { check, sleep, group } from k6; const loginRes http.post(https://test.k6.io/login, { username: admin, password: 123, }); // 1. 从响应体中提取 token假设返回 JSON{token: xxx} const token loginRes.json().token; // 2. 后续请求带上 Authorization Header const authParams { headers: { Authorization: Bearer ${token}, }, }; // 3. 访问受保护接口 const profileRes http.get(https://test.k6.io/me, authParams); check(profileRes, { profile status 200: (r) r.status 200, });注意K6 的http模块默认不解析 JSON 响应体必须显式调用.json()方法。如果响应不是合法 JSON.json()会抛异常导致脚本中断。生产环境建议加 try-catchlet token; try { token loginRes.json().token; } catch (e) { console.error(Failed to parse login response:, loginRes.body); throw e; }3.4 第四层断言可信 —— 用多维度指标替代单一状态码只检查status 200是危险的。API 可能返回 200 但内容是{ error: rate limit exceeded }或者数据库连接池耗尽时返回 200 空白 HTML。我们必须结合业务语义做断言。以商品搜索接口为例期望返回 JSON 数组且至少包含 5 个商品const searchRes http.get(https://test.k6.io/search?qmobile); check(searchRes, { search status 200: (r) r.status 200, search response is JSON: (r) r.headers[Content-Type]?.includes(application/json), search has at least 5 items: (r) { try { const data r.json(); return Array.isArray(data.results) data.results.length 5; } catch (e) { return false; } }, search response time 800ms: (r) r.timings.duration 800, });实战经验我们在线上压测中发现某次数据库慢查询导致接口平均响应时间从 120ms 升至 650ms但所有status 200断言仍通过。加入r.timings.duration 800后立刻在 CI 报告中标红推动 DBA 优化索引。性能测试的断言必须同时覆盖功能正确性what和性能达标性how fast。4. 执行与解读读懂 K6 输出的每一行数字意味着什么k6 run script.js的默认输出信息量极大但多数人只扫一眼✓ is status 200就关掉终端。实际上K6 的实时输出是诊断性能瓶颈的第一现场。下面逐行拆解一个典型输出片段并说明每个指标的业务含义。4.1 默认输出结构解析以 10 个 VU、30 秒测试为例/\ |‾‾| /‾‾/ /‾‾/ /\ / \ | |/ / / / / \/ \ | ( / ‾‾\ / \ | |\ \ | (‾) | / __________ \ |__| \__\ \_____/ .io execution: local script: script.js output: - scenarios: (100.00%) 1 scenario, 10 max VUs, 30s max duration (incl. graceful stop): * default: 10 looping VUs for 30s (gracefulStatus: 30s) INFO[0000] writing results to stdout INFO[0000] using local time zone INFO[0000] no configuration file provided INFO[0000] no environment file provided running (00m30.0s), 00/10 VUs, 27 complete and 0 interrupted iterations default ✓ [] 10 VUs 00m30.0s/30s 27/27 iters, 270 reqs data_received........: 1.2 MB 28 kB/s data_sent............: 120 kB 2.8 kB/s http_req_blocked.....: avg1.2ms min0s med0.8ms max12ms p(90)3.5ms p(95)5.1ms http_req_connecting..: avg0.4ms min0s med0.3ms max4.2ms p(90)0.9ms p(95)1.3ms http_req_duration....: avg124ms min82ms med118ms max210ms p(90)165ms p(95)182ms http_req_failed......: 0.00% ✓ 0 ✗ 270 http_req_receiving...: avg0.3ms min0s med0.2ms max1.8ms p(90)0.5ms p(95)0.7ms http_req_sending.....: avg0.1ms min0s med0s max0.4ms p(90)0.1ms p(95)0.2ms http_req_tls_handshaking: avg0.8ms min0s med0.6ms max3.1ms p(90)1.5ms p(95)2.0ms http_req_waiting.....: avg123ms min82ms med117ms max209ms p(90)164ms p(95)181ms http_reqs............: 270 8.999515/s iteration_duration...: avg1.01s min1.01s med1.01s max1.02s p(90)1.02s p(95)1.02s iterations...........: 27 0.899952/s vus..................: 10 min10 max10 vus_max..............: 10 min10 max10我们重点看http_req_*开头的指标指标名含义业务解读健康阈值参考http_req_duration整个 HTTP 请求耗时从 DNS 解析后到响应结束用户感知的“页面打开时间”Web 应用 500msAPI 200mshttp_req_waitingTTFBTime To First Byte即服务端处理时间后端逻辑、数据库查询、缓存命中率的综合体现占duration的 80% 说明瓶颈在服务端http_req_blocked浏览器/客户端等待可用 socket 的时间客户端连接池不足、DNS 解析慢、防火墙策略 5ms 需查客户端配置http_req_connectingTCP 连接建立耗时网络延迟、服务端连接数上限 2ms 需查网络链路http_req_tls_handshakingTLS 握手耗时证书链长度、密钥交换算法、服务端 TLS 配置 3ms 需优化 TLS 设置关键洞察http_req_duration http_req_blocked http_req_connecting http_req_tls_handshaking http_req_waiting http_req_sending http_req_receiving。如果waiting占比过高如 95%说明优化方向是后端代码如果blocked或connecting突增说明是客户端或网络问题。4.2 如何用--out导出结构化结果进行深度分析默认输出是实时流无法回溯。生产环境必须导出为结构化格式# 导出为 JSON Lines每行一个指标事件适合 ELK/ClickHouse k6 run --out jsonresults.json script.js # 导出为 InfluxDB Line Protocol直连监控系统 k6 run --out influxdbhttp://localhost:8086/k6 script.js # 导出为 CSVExcel 可读适合汇报 k6 run --out csvresults.csv script.jsresults.json示例截取一行{ type: Point, metric: http_req_duration, data: { time: 2024-03-15T10:22:33.456Z, value: 124.3, tags: { name: https://test.k6.io/, method: GET, status: 200 } } }实战技巧我们团队将k6 run --out json-的输出通过管道交给jq实时过滤关键指标k6 run script.js --out json- 2/dev/null | \ jq -c select(.type Point and .metric http_req_duration and .data.value 500) | \ tee slow_requests.json这条命令会实时捕获所有耗时 500ms 的请求并存入slow_requests.json方便后续做火焰图或日志关联。4.3 常见误读与避坑指南误区一“RPS VUs / average_response_time”这是经典错误。K6 的 RPShttp_reqs由VUs × (1 / (avg_duration sleep))决定。如果avg_duration100mssleep1s则单个 VU 的 RPS ≈ 0.910 个 VU 约 9 RPS。不要用VUs / avg_duration粗略估算务必看http_reqs实际值。误区二“p95 响应时间翻倍 服务崩溃”p95 翻倍可能只是少数慢查询只要http_req_failed仍为 0%且 p50 稳定说明服务仍有容量。真正危险的是http_req_failed 0%或vus开始掉vus曲线下降那才是雪崩前兆。误区三“本地跑得快线上就一定稳”本地测试受本机 CPU、网络、DNS 影响极大。我们曾遇到本地 p9580ms线上 p95420ms 的案例。根因是本地 DNS 解析走/etc/hosts而线上走公司内网 DNS后者有额外 300ms 延迟。压测环境必须尽可能贴近生产环境同机房、同网络段、同 DNS 配置。最后分享一个硬核技巧用k6 inspect静态分析脚本结构提前发现潜在问题k6 inspect script.js # 输出包括导入的模块、导出的函数、使用的 K6 API、是否有未使用的变量等 # 特别有用检查是否误用了 Node.js 内置模块如 fs、pathinspect 会明确标出 Unknown module: fs这个命令不执行脚本纯静态扫描是 CI 流水线里做脚本合规检查的利器。我在实际项目中用 K6 做过三次大规模压测一次是支付网关上线前的 10 万 TPS 验证一次是大促预案的熔断阈值校准还有一次是排查一个凌晨三点偶发的 502 错误。每次都不是靠“多开几个 VU”解决的而是靠读懂http_req_waiting和http_req_blocked的微妙变化再结合应用日志定位到具体线程池或连接池配置。K6 本身不解决性能问题但它把问题暴露得足够清晰、足够及时——这才是它不可替代的价值。
