很多团队至今仍把性能测试当成一次性的"上线前仪式"：版本冻结、拉个压测环境、跑一轮 JMeter、出一份 Word 报告，然后归档。问题在于，当系统架构演进为由几十个微服务组成、由 Kubernetes 调度、由 Istio 做服务治理的复杂拓扑时，这种一次性动作已经无法反映真实的系统容量。 工具层面的变化最先发生。JMeter 依然是覆盖面最广的经典选择，图形化界面、丰富的协议插件、庞大的社区资料，使它在传统企业应用和协议多样的场景中难以替代。但它基于线程模型的并发实现，在单机模拟数万并发时资源开销明显，脚本以 XML 形式存储也不利于代码评审和版本管理。 k6 走的是另一条路。它用 Go 语言实现底层引擎，以 JavaScript 编写脚本，单机可支撑的虚拟用户数远高于同等配置下的 JMeter，且脚本天然就是纯文本代码，可以直接进入 Git 仓库参与 Code Review。对于云原生技术栈的团队来说，"性能测试即代码"的理念与现有工程习惯高度契合。此外还有 Gatling、Locust 等选项，前者在报告可读性上表现出色，后者对 Python 团队非常友好。 但工具选型只是起点，真正的分水岭在于能否实现常态化。所谓自动化性能测试，指的是脚本自动化、场景自动化、执行自动化、报告自动化乃至优化建议自动化的全链路闭环。脚本可以通过接口文档导入或低代码拖拽生成，避免每次从零编写；场景中预置压测策略、监控指标和告警阈值；执行环节与 Jenkins、GitLab CI 对接，代码提交后自动触发；压测结束自动生成可视化报告并推送到群组。 这样做的直接收益是把性能问题的发现时点大幅前移。当每一次迭代都自动跑一轮基准压测，团队就能看到 P99 延迟的趋势曲线，而不是等到大促当天才发现某个接口悄悄劣化了三倍。趋势本身，往往比单次的绝对数值更有价值。 落地时有几个务实建议：第一，压测环境的配置和数据量要尽量贴近生产，否则结论会严重失真；第二，指标不能只看 TPS 和响应时间，必须同步采集 CPU、内存、GC 频率、数据库连接池、慢查询等资源侧数据，否则只知道慢，不知道为什么慢；第三，为核心链路设定明确的性能基线，把它作为流水线的质量门禁。 性能测试的终点不是一份漂亮的报告，而是让容量水位成为团队随时可查的常规指标。当它像单元测试覆盖率一样自然地出现在每次构建结果里，性能治理才算真正走上正轨。