凌晨两点，压力测试我把最后一行代码提交到测试分支，压力测试顺手点了“触发流水线”。压力测试屏幕右下角弹出一行绿字：压力测试已启动。压力测试那一刻我脑子里想的压力测试不是系统会不会崩，而是压力测试——它最好崩得有点价值。

很多人以为压力测试就是压力测试拿工具猛怼接口，看QPS能飙到多少。压力测试我最初也这么干过。压力测试2019年做一个电商秒杀项目，压力测试用JMeter开了两千个线程，压力测试结果数据库连接池瞬间打满，压力测试服务直接假死。压力测试当时还沾沾自喜，压力测试觉得发现了大问题。压力测试后来复盘才知道，那台测试机的内存只有8G，跑两千个线程本身就是在压榨操作系统，跟被测服务没多大关系。测试环境的不靠谱，往往比代码缺陷更早暴露。

真正有用的压测，得先想清楚“压什么”。是数据库的写入瓶颈？是网关的转发效率？还是某个第三方接口的响应延迟？我见过一个团队，花了两周压测订单服务，报告写了四十页，最后上线还是挂了。原因很简单——他们没压支付回调。那个回调接口依赖外部银行，平时响应200毫秒，促销期间银行自己限流，直接变成5秒超时。压测环境里银行接口是mock的，永远秒回。这种盲区，工具再好也测不出来。

说个具体的。去年帮朋友看一个直播弹幕服务。平时在线几千人，弹幕流畅得很。他们搞了一次压测，模拟五万人同时发弹幕。结果消息队列的消费者线程全部堵死，因为每条弹幕都要查一次用户等级，而用户等级服务是个同步的HTTP调用。五万条弹幕就是五万次HTTP请求，线程池瞬间耗尽。后来改成批量查、加本地缓存，再压，CPU上去了，但消息延迟稳定在80毫秒以内。你看，压力测试暴露的不是“系统能扛多少”，而是“哪个环节最先扛不住”。

还有个容易被忽略的点：压测的节奏。真实流量不是匀速的。秒杀开始那一秒，流量是尖刺；直播抽奖那一刻，弹幕是脉冲。用固定线程数压十分钟，数据好看，但没意义。我习惯用阶梯式加压——每30秒加500并发，直到错误率超过1%或者响应时间突破阈值。这样能看到系统从健康到恶化的完整曲线，而不是一个孤零零的峰值数字。曲线拐点在哪，扩容的临界点就在哪。

工具方面，JMeter、Locust、wrk我都用过。JMeter图形化方便，但吃内存；Locust用Python写脚本灵活，适合复杂场景；wrk轻量，适合快速摸底。没有哪个最好，看你要压什么。我现在的习惯是先用wrk快速扫一遍，找到大致瓶颈，再用Locust写业务逻辑做精细化压测。别迷信工具报告里的“TPS”，那玩意儿受测试机性能影响太大。我见过一台16核的机器压出8万TPS，换到4核的机器上只剩1万2。被测服务没变，测试机成了瓶颈。

最后说个反直觉的结论：压测通过不代表线上没问题。线上有网络抖动、有磁盘IO竞争、有邻居服务抢CPU。压测环境太干净了。我的做法是，压测通过后，再在预发环境做一次“混沌压测”——随机杀掉一个节点，或者注入200毫秒网络延迟，看系统能不能自愈。能扛住这种折腾的，上线才稍微放心。

凌晨两点四十七分，流水线跑完了。报告显示：在800并发下，P99响应时间从120毫秒涨到340毫秒，错误率0.3%。没有崩溃，但已经摸到了软肋。我关掉屏幕，心想明天得把那个用户等级查询改成异步。压力测试最诚实的地方就在这儿——它不骗你，只是你愿不愿意听。