可复现的容量基准测试关键在于标准化脚本固化全部条件：固定输入与负载、环境隔离与状态归零、统一监控口径、结构化输出。
容量基准测试要确保多次运行结果可复现，关键不是“多跑几次”，而是让每次运行的条件完全一致。标准化测试脚本是实现这一目标的核心载体，它把环境、数据、流程、清理机制全部固化下来，消除人为干预和随机扰动。
固定输入与可控负载
容量测试高度依赖稳定的请求模型和数据规模。标准化脚本需明确声明：
- 并发用户数、RPS 或 QPS 的具体数值及增长模式（如阶梯式、恒定式）
- 使用预生成的、版本受控的测试数据集（如 JSON 文件或数据库快照），避免运行时动态生成带来的分布偏差
- 所有请求参数（如 URL 路径、Header、Body 内容）硬编码或通过配置文件注入，禁止随机 ID、时间戳等不可控字段
环境隔离与状态归零
一次测试的结果不该被前一次残留状态污染。标准化脚本必须内置：
- 初始化逻辑：自动拉起指定版本的容器服务、重置数据库到已知快照、清空缓存（如 Redis flushdb）
- 清理逻辑：测试结束后自动关闭连接、删除临时文件、恢复配置项，且无论成功或失败都执行
- 环境标识：在脚本中嵌入环境标签（如 env=staging-v2.4.1），确保结果可追溯到确切部署状态
计时与资源监控的统一口径
容量指标（如 P95 延迟、吞吐量、CPU 使用率）若采集方式不一致，就无法横向对比。标准化脚本应：
- 统一启用高精度计时（如 Go 的 testing.B 自动迭代 + b.ResetTimer()，或 PHP 的 hrtime(true)）
- 集成标准监控探针（如 Prometheus Exporter、cgroup 统计），在相同采样频率和时间窗口下抓取资源数据
- 禁用非必要后台任务（如日志轮转、定时聚合），防止干扰主线程性能表现
执行过程与结果输出结构化
可复现性不仅指“能再跑一遍”，更指“跑完能准确比对”。标准化脚本需保证：
- 输出格式统一（如 JSON Schema 固定字段：timestamp, scenario, concurrency, p95_ms, tps, cpu_avg, mem_peak_mb）
- 每次执行自动生成唯一运行 ID，并关联 Git 提交哈希、脚本版本号、被测二进制 SHA256
- 支持重复执行命令（如 go test -bench=BenchmarkAPIPost -count=5 -benchmem），并用 benchstat 等工具自动计算差异显著性
不复杂但容易忽略——真正的可复现，不在脚本写得多漂亮，而在每处变量是否都被锁定、每次启动是否都从同一“干净起点”开始。
