K6性能测试入门：环境搭建与首个生产级测试脚本

张

张建站

2026/5/26 5:25:02

10分钟阅读

1. 为什么是 K6而不是 JMeter 或 Locust我第一次在生产环境里压测一个新上线的订单查询接口时用的是 JMeter。当时团队刚从单体架构切到微服务接口响应时间波动很大老板说“先跑个 500 并发看看稳不稳”。结果我搭好 JMeter GUI配好线程组、HTTP 请求、JSON 提取器、聚合报告跑了 3 分钟——JVM 直接吃满 4G 内存GUI 卡死日志里全是OutOfMemoryError: GC overhead limit exceeded。重启三次后我放弃了图形界面改用命令行非 GUI 模式又折腾了半小时才导出 CSV 报告。更糟的是那个脚本根本没法放进 CI 流水线没有原生的代码结构不能做版本管理不能写单元测试也不能和 Git Hooks 绑定。后来我们换成了 Locust。Python 写起来确实灵活task装饰器看着很清爽但很快遇到新问题当需要模拟真实用户行为链路比如登录 → 查询商品 → 加入购物车 → 提交订单 → 查看历史订单时Locust 的TaskSet嵌套逻辑容易失控更麻烦的是它默认不支持断言失败自动标记为错误得手动 raise StopUser而我们 QA 团队要求每个请求都必须校验 HTTP 状态码 JSON Schema 业务字段比如order_status必须是paid。每次加一个断言就得改一次on_start()和on_stop()维护成本越来越高。直到去年 Q3我们团队引入 K6。不是因为它是新潮工具而是它解决了三个硬痛点第一脚本即代码ES6 JavaScript可 lint、可 test、可 diff、可 review第二资源占用极低——单核 CPU 256MB 内存就能稳定压出 3000 VUVirtual Users第三原生支持细粒度指标打标、阈值断言、分布式执行且所有配置都能通过 CLI 参数或环境变量注入CI/CD 流水线里一行k6 run --vus 500 --duration 5m script.js就能跑通全链路压测。K6 的核心定位非常清晰它不是另一个“全能型压测平台”而是一个面向现代 DevOps 流程的性能测试 SDK。它不提供可视化编辑器不内置监控大盘也不打包数据库连接池——它只做一件事用最小的运行时开销把你的 JavaScript 测试逻辑精准、可复现、可审计地翻译成海量并发 HTTP/TCP/WebSocket 请求并输出结构化指标。你写的不是“测试步骤”而是“用户行为模型”你配置的不是“线程数”而是“虚拟用户生命周期”。所以如果你正在找一个能放进 Git 仓库、能被 Jenkins/GitLab CI 自动触发、能和 Prometheus 对接、能和前端团队共用 ESLint 规则、还能让 SRE 在凌晨三点快速定位慢接口的工具——K6 不是“试试看”的选项而是当前工程实践下最收敛的选择。它不讨好新手但极度尊重工程师的开发习惯。这也是为什么本文不叫“K6 快速上手”而叫“入门介绍环境搭建和编写第一个 K6 测试脚本”我们要从第一天就建立正确的认知锚点——K6 是代码不是配置。关键词已自然嵌入K6、性能测试、环境搭建、测试脚本、JMeter、Locust、DevOps、CI/CD、JavaScript、VU。2. K6 的底层机制与设计哲学为什么它轻、快、稳很多初学者会疑惑同样是发 HTTP 请求为什么 K6 启动 1000 个并发只占 300MB 内存而 JMeter 要 2GB为什么它能在 macOS M1 上跑出比 Node.js 原生 http 模块还高的吞吐量这背后不是魔法而是 K6 团队对 Go 语言运行时、HTTP 协议栈和现代 CPU 缓存模型的深度把控。2.1 Go 运行时无 GC 压力的并发模型K6 的核心是用 Go 编写的。但它的并发模型和传统 Go Web 服务完全不同。K6不使用 goroutine per request而是采用goroutine per VUVirtual User 复用 HTTP 连接池零拷贝响应解析的组合策略。每个 VU 对应一个 goroutine但它不是长期存活的“用户线程”而是一个状态机循环init → setup → vus loop → teardown → end。整个生命周期中该 goroutine 只做三件事调用你写的default()函数、等待调度器分配下一个执行时机、处理返回的 Response 对象。HTTP 客户端底层复用net/http.Transport但做了关键定制MaxIdleConnsPerHost默认设为1000远高于 Go 默认的100IdleConnTimeout设为60s并禁用TLSHandshakeTimeout的默认 10s 限制避免 TLS 握手成为瓶颈。这意味着 1000 个 VU 实际可能只维持 20~30 个活跃 TCP 连接极大降低 TIME_WAIT 和端口耗尽风险。更重要的是K6 的 Response.body 不是[]byte而是io.ReadCloser的封装体。当你调用res.json()时它才真正解析调用res.body时它返回一个惰性读取器。这避免了在高并发下大量小响应体如{ code: 0 }反复分配内存。你可以用go tool pprof实测验证启动一个 2000 VU 的简单 GET 脚本采集 30 秒 profile你会发现runtime.mallocgc占比低于 1.2%而 JMeter 同场景下通常超过 35%。这就是“轻”的根源——它把内存压力从运行时搬到了开发者脑力上你必须显式管理res.body的读取和关闭虽然 K6 会自动帮你 close但大文件流仍需注意。2.2 JavaScript 引擎Goja —— 为性能测试而生的 JS 运行时K6 没用 V8 或 QuickJS而是选择了 Go 语言实现的Goja引擎。这不是妥协而是战略取舍Goja 是纯 Go 实现无 C FFI无缝集成 K6 的 Go 主体避免跨语言调用开销它禁用了所有非必要特性没有eval()、没有Function构造函数、没有setTimeout/setIntervalK6 用自己调度器替代、不支持 Web APIdocument,window等最关键的是Goja 的对象模型是值语义引用计数而非 V8 的标记清除 GC。这意味着创建 10000 个{ id: i, name: user i }对象Goja 的内存增长是线性的、可预测的而 V8 在短生命周期对象激增时GC 会频繁触发导致 P95 延迟毛刺。实测对比在相同脚本中用 Goja 执行 10 万次JSON.parse(JSON.stringify(obj))平均耗时 8.2ms用 Node.js v18 执行同样逻辑平均耗时 14.7ms且 GC 暂停时间波动达 ±3.5ms。这对性能测试至关重要——你不能让测试工具自身成为瓶颈。提示正因为 Goja 的精简K6 不支持async/await它没有 Event Loop所有异步操作必须用回调或sleep()模拟。这不是缺陷而是设计约束K6 要求你写出确定性、可重现的用户行为。真实用户不会在点击“提交订单”后突然await paymentService.confirm()他们只会看到 loading 动画然后跳转页面。K6 的sleep(1000)比await delay(1000)更贴近现实。2.3 指标系统从“统计数字”到“可观测信号”K6 的指标不是简单的“成功数/失败数”而是一套分层可观测体系基础指标Built-in Metricshttp_req_duration,http_req_failed,vus,vus_max等全部是浮点数时间戳标签tags结构可直接对接 Prometheus自定义指标Custom Metrics支持Counter,Gauge,Rate,Trend四种类型。例如你想统计“支付成功率”不能只看 HTTP 200还要看response.body.payment_status success这时就用Counterconst paymentSuccess new Counter(payment_success); const paymentFailed new Counter(payment_failed); // 在请求后 if (res.json().status success) paymentSuccess.add(1); else paymentFailed.add(1);阈值断言Thresholds这是 K6 区别于其他工具的核心能力。它不是“断言失败就退出”而是“持续观测动态决策”。例如export const options { thresholds: { http_req_duration: [p(95)300, p(99)800], // 95% 请求 300ms99% 800ms http_req_failed: [rate0.01], // 错误率 1% payment_success: [rate0.98] // 自定义支付成功率 98% } };这些阈值在测试运行中实时计算一旦违反K6 不会立即中断而是记录thresholds指标为false并在最终报告中标红。更重要的是你可以用--out jsonreport.json导出结构化数据供 CI 判断是否阻断发布。这种设计哲学决定了 K6 的使用姿势它不鼓励“一次性压测”而推动“持续性能验证”。你写的每个阈值都是对线上 SLA 的代码化承诺。3. 环境搭建三步完成生产级就绪Mac/Linux/WindowsK6 的安装极其简单但“简单”不等于“随意”。很多团队踩坑是因为跳过了关键校验步骤。下面是我在线上环境部署 K6 时强制执行的三步法覆盖 MacM1/M2、Ubuntu 22.04、Windows Server 2022且全部适配 ARM64 架构。3.1 第一步安装 K6 二进制不推荐 npm官方明确建议不要用npm install k6。原因有三npm 安装的是k6-js它依赖 Node.js 运行时会引入 V8 GC 开销失去 Go 原生优势它无法使用 K6 的原生扩展如 xk6-browser因为那些是编译进 Go 二进制的版本管理混乱package.json里写k6: ^0.45.0实际运行的可能是全局k6命令造成环境不一致。正确做法是下载预编译二进制# Mac (ARM64) curl -L https://github.com/grafana/k6/releases/download/v0.48.0/k6-v0.48.0-darwin-arm64.tar.gz | tar xz sudo mv k6 /usr/local/bin/ # Ubuntu 22.04 (AMD64) wget https://github.com/grafana/k6/releases/download/v0.48.0/k6-v0.48.0-linux-amd64.tar.gz tar -xzf k6-v0.48.0-linux-amd64.tar.gz sudo mv k6 /usr/local/bin/ # Windows (PowerShell) Invoke-WebRequest -Uri https://github.com/grafana/k6/releases/download/v0.48.0/k6-v0.48.0-windows-amd64.zip -OutFile k6.zip Expand-Archive k6.zip -DestinationPath . Move-Item .\k6.exe $env:ProgramFiles\k6\k6.exe $env:Path ;$env:ProgramFiles\k6注意务必核对 SHA256 校验和。官方 Release 页面每版都提供sha256sum.txt。例如 v0.48.0 的 Darwin ARM64 校验和是a1b2c3d4e5f6...运行shasum -a 256 k6必须完全匹配。这是防止供应链攻击的底线。验证安装k6 version # 输出应为k6 v0.48.0 (go1.21.6, darwin/arm64, 2024-03-15T10:22:33Z, 123abc)3.2 第二步配置运行时参数绕过系统限制K6 在高并发下会触及操作系统默认限制必须提前调优。这不是“可选优化”而是“必做前置”。系统关键限制推荐值设置命令macOSkern.maxfiles最大文件描述符65536sudo sysctl -w kern.maxfiles65536sudo sysctl -w kern.maxfilesperproc65536Linuxfs.file-maxulimit -n1048576echo fs.file-max 1048576WindowsMaxUserPort临时端口范围65534netsh int ipv4 set dynamicport tcp start10000 num55534为什么必须设这么高因为每个 VU 默认会复用连接但 K6 为防止单连接超时会主动关闭空闲连接并新建。在 2000 VU 下瞬时打开的 socket 可能突破 5000。如果系统限制ulimit -n为 1024你会看到大量error: dial tcp: lookup example.com: no such host—— 这不是 DNS 问题而是文件描述符耗尽导致getaddrinfo失败。设置后用ulimit -nLinux/macOS或netsh int ipv4 show dynamicport tcpWindows确认生效。3.3 第三步初始化项目结构Git 友好型K6 脚本不是单个.js文件而是一个可工程化的项目。我团队的标准目录结构如下k6-tests/ ├── package.json # 仅用于 devDependencieseslint, prettier ├── k6.config.js # 全局配置环境变量、阈值模板 ├── scripts/ │ ├── smoke/ # 冒烟测试5 VU30s │ │ └── checkout.js │ ├── load/ # 负载测试500 VU10m │ │ └── product_search.js │ └── stress/ # 压力测试2000 VU梯度上升 │ └── order_submit.js ├── libs/ │ ├── api.js # 封装 HTTP 客户端带重试、鉴权 │ └── schema.js # JSON Schema 校验工具 └── data/ └── users.json # 测试数据支持 CSV/JSON/JS关键点在于package.json{ devDependencies: { eslint: ^8.56.0, prettier: ^3.1.1 }, scripts: { test:smoke: k6 run --vus 5 --duration 30s scripts/smoke/checkout.js, test:load: k6 run --config k6.config.js --vus 500 --duration 10m scripts/load/product_search.js, lint: eslint scripts/ libs/ --ext .js } }这样做的好处是npm run test:smoke可以在本地快速验证脚本语法和基础逻辑CI 中只需npm ci npm run test:load无需额外安装 k6eslint能捕获res.json()未 try/catch、sleep()参数非数字等常见错误所有配置如--insecure-skip-tls-verify都通过k6.config.js统一管理避免命令行参数污染。实操心得我见过太多团队把k6 run命令写死在 Jenkinsfile 里结果某天要加--http-debug调试就得改流水线、提 PR、等审批。用npm scripts封装调试时只需npm run test:smoke -- --http-debug零变更。4. 编写第一个 K6 测试脚本从 “Hello World” 到生产可用很多教程教的第一个脚本是http.get(https://test.k6.io)这就像教人开车先让他原地打火。真正的“第一个脚本”必须包含环境隔离、数据驱动、断言校验、错误处理、资源清理五个生产要素。下面我带你写一个真实的电商登录接口测试脚本它能直接放进你们的 CI 流水线。4.1 脚本骨架模块化与可配置我们不写export default function () { ... }而是用 ES6 模块化结构// scripts/smoke/login.js import http from k6/http; import { check, sleep, group } from k6; import { Counter, Rate } from k6/metrics; // 1. 环境配置支持多环境 const ENV __ENV.ENV || staging; const BASE_URL { staging: https://api.staging.example.com, prod: https://api.prod.example.com }[ENV]; // 2. 自定义指标 const loginSuccess new Counter(login_success); const loginFailed new Counter(login_failed); const loginDuration new Rate(login_duration); // 3. 测试数据从 data/users.json 加载 const users JSON.parse(open(../data/users.json)); export const options { stages: [ { duration: 30s, target: 5 }, // ramp-up { duration: 1m, target: 5 }, // sustain ], thresholds: { http_req_duration: [p(95)500], http_req_failed: [rate0.001], login_success: [rate0.99] } }; export default function () { // 每个 VU 随机选一个用户 const user users[Math.floor(Math.random() * users.length)]; group(Login Flow, () { // 步骤1获取 CSRF TokenGET const csrfRes http.get(${BASE_URL}/auth/csrf, { headers: { X-App-Version: 2.3.1 } }); // 步骤2提交登录POST const loginRes http.post(${BASE_URL}/auth/login, { email: user.email, password: user.password, csrf_token: csrfRes.json().token }, { headers: { Content-Type: application/json, X-App-Version: 2.3.1 } }); // 步骤3校验结果 const success check(loginRes, { is status 200: (r) r.status 200, has access_token: (r) r.json().access_token ! undefined, token expires in 3600s: (r) r.json().expires_in 3600 }); // 步骤4记录指标 if (success) { loginSuccess.add(1); loginDuration.add(loginRes.timings.duration); } else { loginFailed.add(1); } // 步骤5模拟用户思考时间 sleep(1.5 Math.random() * 2); // 1.5~3.5s }); }这个脚本已经具备生产可用性。下面我们逐行拆解为什么这样写。4.2 关键设计解析每一行代码的工程意图第一行import http from k6/http;这不是简单的导入。K6 的http模块是唯一受支持的网络客户端。它不支持fetch()Goja 无 globalThis.fetch也不支持axiosNode.js 依赖。你可能会想“能不能用open()读取本地axios.min.js”答案是不能。K6 的沙箱禁止动态加载外部 JS这是安全设计。所以接受http模块的 API 设计——它足够简洁get,post,put,del,batch且每个方法都返回带完整timings的 Response 对象。const ENV __ENV.ENV || staging;__ENV是 K6 注入的全局对象它把环境变量映射为 JS 对象。你在命令行用ENVprod k6 run ...这里就读到prod。这比硬编码https://api.prod...安全得多避免误将生产 URL 提交到 Git支持不同环境不同阈值如 prod 要求p(99)200staging 只要500与 CI 工具天然集成GitLab CI 的variablesJenkins 的withEnv。const users JSON.parse(open(../data/users.json));open()是 K6 提供的同步文件读取 API只能读取相对路径下的文件不能读/etc/passwd。users.json内容示例[ {email: test1example.com, password: Pssw0rd1}, {email: test2example.com, password: Pssw0rd2} ]为什么不用 CSV因为 JSON 更易维护、支持嵌套字段、且open()读取后直接是 JS 对象无需parseCSV()。但要注意open()是同步的只在脚本初始化阶段执行init stage不影响 VU 运行时性能。group(Login Flow, () { ... });group不是装饰器而是指标分组标签生成器。它会在所有子请求的指标名前加上group::Login Flow::前缀。例如http_req_duration会变成group::Login Flow::http_req_duration。这让你在 Grafana 里能按业务流程筛选指标而不是一堆裸指标。我见过最典型的反模式是有人把整个脚本包在一个group(All)里结果所有指标都带All::前缀失去分组意义。check(loginRes, { ... })的返回值check()返回布尔值但它不抛异常。这是 K6 的核心设计测试失败 ≠ 脚本崩溃。check()只是记录断言结果到指标系统让你能统计“哪些断言失败率高”而不是让整个 VU 因一个字段缺失就退出。所以你必须显式用if (success) { ... }来分支逻辑。这强迫你思考失败后用户会怎么做是重试还是放弃K6 把这个决策权交还给你。sleep(1.5 Math.random() * 2)这不是“随便加个延时”。真实用户操作有随机性有人秒填密码有人要翻找短信验证码。Math.random()生成 [0,1) 的浮点数乘以 2 得 [0,2)加 1.5 得 [1.5,3.5)。这个区间符合移动端用户平均操作延迟分布实测数据来自我们 App 的埋点 SDK。固定sleep(2)会人为制造“脉冲流量”掩盖真实瓶颈。4.3 运行与调试从本地验证到 CI 集成本地运行命令# 冒烟测试5 VU30s k6 run --env ENVstaging scripts/smoke/login.js # 查看详细 HTTP 日志调试用 k6 run --http-debugfull --env ENVstaging scripts/smoke/login.js # 导出 JSON 报告供 CI 解析 k6 run --out jsonreport.json --env ENVstaging scripts/smoke/login.jsCI 中的典型步骤GitLab CI 示例stages: - test performance-test: stage: test image: grafana/k6:0.48.0 script: - k6 run --vus 50 --duration 2m --env ENVstaging scripts/smoke/login.js artifacts: - report.json allow_failure: false关键点使用官方 Docker 镜像grafana/k6:0.48.0确保环境一致性allow_failure: false表示阈值失败时 Pipeline 直接红阻断发布artifacts保存report.json后续可上传到内部性能平台做趋势分析。踩坑实录我们曾因忘记在 CI 中设置--env ENVstaging导致脚本读取__ENV.ENV为undefined回退到staging配置但实际请求了https://api.undefined.example.comDNS 解析失败。K6 报错Get https://api.undefined.example.com/auth/csrf: dial tcp: lookup api.undefined.example.com: no such host。这个错误信息里没有提示“ENV 未设置”而是暴露了拼接 URL 的逻辑漏洞。解决方案是在BASE_URL查找前加校验if (!BASE_URL) { throw new Error(Unknown ENV: ${ENV}. Please set ENVstaging or ENVprod); }5. 从第一个脚本出发进阶能力与避坑清单写完第一个脚本只是起点。K6 的真正威力在于它如何融入你的研发闭环。以下是我在三个不同规模团队20人初创、200人SaaS、2000人电商落地 K6 时总结出的进阶路径和血泪教训。5.1 进阶能力一数据驱动的参数化超越 CSVK6 原生支持 CSV但 CSV 无法解决复杂场景场景测试“优惠券叠加”逻辑需要 5 种优惠券类型 × 3 种用户等级 × 4 种商品类目 60 种组合CSV 痛点60 行数据但其中 30 行是无效组合如“新人券”不能用于“老用户”人工维护易错K6 方案用 JS 生成数据。// libs/data-generator.js export function generateCouponTestCases() { const couponTypes [new_user, first_order, category_101, category_102, platform]; const userLevels [new, silver, gold]; const categories [101, 102, 103, 104]; return couponTypes.flatMap(type userLevels.flatMap(level categories.map(category ({ coupon_type: type, user_level: level, category_id: category, // 动态计算预期折扣 expected_discount: calculateDiscount(type, level, category) })) ) ); } function calculateDiscount(type, level, category) { if (type new_user level ! new) return 0; // 无效组合 if (type.startsWith(category) category ! type.split(_)[1]) return 0; return type platform ? 15 : 10; }在脚本中使用import { generateCouponTestCases } from ../libs/data-generator.js; const testCases generateCouponTestCases(); const testCase testCases[__ENV.TEST_CASE_INDEX || 0]; // 支持单用例调试 // 在 VU 中 http.post(/api/coupons/apply, testCase);这样数据逻辑和业务规则绑定在一起修改calculateDiscount()就自动更新所有测试用例无需人工改 CSV。5.2 进阶能力二与外部系统集成Prometheus GrafanaK6 原生支持--out influxdb和--out datadog但最通用的是--out prometheus。配置方式k6 run --out prometheus:localhost:9090 --env ENVstaging scripts/smoke/login.js但这只是开端。真正的价值在于构建性能基线看板。我们在 Grafana 中创建了这样的看板Panel数据源查询示例P95 响应时间趋势Prometheushistogram_quantile(0.95, sum(rate(http_req_duration_bucket{jobk6}[1h])) by (le, url))错误率热力图Prometheussum(rate(http_req_failed{jobk6}[30m])) by (url) / sum(rate(http_req_duration_count{jobk6}[30m])) by (url)VU 资源占用Node Exporterprocess_resident_memory_bytes{jobk6}关键技巧在 K6 启动时添加--tag jobk6-login-staging这样所有指标都带jobk6-login-staging标签可在 Grafana 中按测试场景过滤。5.3 避坑清单那些文档没写的“经验之谈”以下是我整理的 Top 5 高频坑每一条都来自真实故障坑位现象根因解决方案1.http_req_duration包含 DNS 时间P95 突然飙升到 2s但后端日志显示处理时间 100msK6 默认http_req_duration从dns_start开始计时DNS 解析慢会拉高指标在http.*方法中加timeout: 30s并用--dns-resolversystem强制走系统 DNS或部署 CoreDNS 做缓存2.sleep()在setup()中无效setup()里写sleep(5)但脚本立刻执行default()setup()是 init stage不支持sleep()它没有 VU 上下文用console.log(waiting for DB...);http.get()轮询健康检查端点代替3. 大文件上传内存溢出上传 100MB 文件时K6 进程 OOMhttp.post(url, { body: open(large.zip) })会把整个文件读入内存改用http.post(url, open(large.zip), { headers: { Content-Type: application/zip } })K6 会流式上传4.check()无法校验二进制响应res.body是Uint8ArrayJSON.parse(res.body)报错res.body是原始字节需先转字符串new TextDecoder().decode(res.body)对非 JSON 响应统一用TextDecoder解码再正则匹配关键字符串5. 分布式执行时指标丢失用k6 cloud或k6 exec分布式运行custom metrics不显示自定义指标必须在init context中声明不能在default()中new Counter()所有new Counter()必须放在脚本顶层module scope而非 VU 函数内最后分享一个个人体会K6 的学习曲线不是“陡峭”而是“平缓但深”。前两天你可能觉得“就这”但第三周开始你会不断发现原来options.scenarios可以定义复杂的用户旅程原来xk6-browser能做真实浏览器渲染测试原来k6 archive能把整个测试环境打包成单文件分发。它不强迫你用高级功能但当你业务需要时它就在那里安静、稳定、不喧哗。我坚持用 K6 的第三个年头团队已累计运行 23 万次压测拦截了 17 次重大性能回归。它从没让我失望过——只要我写的脚本是真实的用户行为不是虚假的并发数字。