公司新上线了个内部报销系统，刚用两天就卡得连提交按钮都点不动；自己写的 Python 脚本处理 10 万条日志，跑着跑着内存直接飙到 95%……这类问题，光靠“感觉”不行，得动手测。
明确目标，别一上来就开干
先想清楚：你到底在担心什么？是用户一并发 500 人登录就崩？还是导出 Excel 要等 3 分钟没人忍得了？把具体场景写下来，比如：
• 支持 800 人同时提交订单，平均响应时间 ≤ 2 秒
• 导入 5GB 日志文件，内存占用不超过 1.5GB
目标越具体，后面选工具、设参数才不跑偏。
挑个趁手的工具，别硬扛
小项目别急着上 JMeter 全家桶。试试这些更轻的：
- Web 页面加载慢？用 Chrome DevTools 的 Network 和 Lighthouse 点两下就有水印、首屏时间、资源瀑布图
- 接口扛不住？
curl配合time命令就能粗筛：time curl -s -o /dev/null http://api.example.com/v1/users - 真要模拟百人并发？JMeter 是稳当选择，但起步建议从“单线程组 + 一个 HTTP 请求 + 查看结果树”开始，跑通再加循环和用户数。
准备真实数据，别全用“test123”
用同一用户名狂刷 100 次登录，和 100 个不同账号真实走一遍流程，压力差得不是一点半点。哪怕只是改个后缀：user_001、user_002……或者用 JMeter 的 CSV Data Set Config 导入手机号+随机密码表，压测结果才站得住脚。
边跑边盯关键指标
启动测试后，眼睛别只盯着“成功/失败”那栏。打开任务管理器（Windows）或 htop（Linux），同步观察：
- CPU 是否持续 >80%
- 内存有没有缓步上涨、迟迟不回收
- 磁盘 I/O 等待时间是否飙升（
iostat -x 1） - 数据库连接池是不是早被占满（看应用日志里 “Waited X ms for connection”）
有一次测后台导出功能，接口返回很快，但服务器 swap 分区狂写——原来是导出逻辑没分页，一次性把千万行数据全 load 进内存。
调参不是玄学，一次只动一个
发现响应变慢了，先别急着改线程数、超时时间、连接池大小。每次只调整一项，比如：
- 把数据库连接池从 10 改成 20，重跑，看 DB 等待是否下降
- 把 JVM 堆内存从 1G 加到 2G，观察 GC 频率是否降低
改完立刻验证，不然你永远不知道到底是哪个改动起了作用。
留档，下次不用重踩坑
截图保存当时的配置（JMeter 的 .jmx 文件、命令行参数、监控曲线）、环境信息（CPU 型号、内存大小、Java 版本）、甚至哪一步开始出现错误日志——这些不是形式主义，是下次遇到类似问题时，翻出来就能对照的救命记录。