Locust压测必须分三层推进：单机验证逻辑、本地多进程摸清资源瓶颈、再上分布式打真实并发；跳过前两层，十万级压测结果不可信。
直接说结论：Locust压测不是“写完脚本就开跑”，它必须分三层推进——单机验证逻辑、本地多进程摸清资源瓶颈、再上分布式打真实并发。跳过前两层，十万级压测结果基本不可信。
为什么locust -f locustfile.py只能用于功能验证，不能当正式压测用
这个命令启动的是单进程单Worker模式，所有协程挤在一个gevent事件循环里。哪怕你设了--users 10000，实际能稳定跑通的并发数取决于：ulimit -n（文件描述符）、本地端口范围（/proc/sys/net/ipv4/ip_local_port_range）、CPU核数和Python GIL调度效率。实测中，一台4核16G云主机在未调优状态下，locust -f最多撑住6000–8000并发，再往上就会出现Cannot assign requested address或响应时间断崖式飙升。
常见错误现象包括：
- Web UI显示用户已全部spawn，但
Requests/s卡在个位数 - 日志里反复出现
ConnectionRefusedError或Timeout，但被测服务监控无压力 - 同一台机器上两个
locust -f进程互相抢端口，第二个直接起不来
如何用locust --master和locust --worker正确启动分布式
关键不是“能不能跑起来”，而是“每个Worker是否真正独立承担负载”。Master不发请求，只做调度和聚合；Worker才是真正的压力源。启动顺序和参数必须严格匹配：
- 先起Master：
locust -f locustfile.py --master --host=http://your-api.com --web-host=0.0.0.0 --web-port=8089 - 再起Worker（可多台机器，也可同机多进程）：
locust -f locustfile.py --worker --master-host=192.168.1.100 --master-port=5557（IP填Master所在机器的实际内网IP） - 总并发数由Master Web界面或
--users参数统一控制，Worker自动按数量均分，比如10000用户、4个Worker，每个Worker约跑2500协程
容易踩的坑：
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- Worker连不上Master时，不会报错，只会静默等待——检查
firewall-cmd --list-ports是否放行5557（通信端口）和5558（事件端口） - 不同Worker的Python环境不一致（比如一个装了
requests[socks]，另一个没装），会导致部分Worker请求失败但无提示 - Worker进程名默认是
locust，ps aux | grep locust会看到一堆，建议加--process-name="locust-worker-01"便于区分
HttpUser类里哪些字段会影响分布式压测的真实性和稳定性
不是所有字段在分布式下都“透明生效”。有些只在单Worker内起作用，有些则跨Worker影响全局行为：
-
wait_time = between(1, 5)：每个Worker独立执行，不影响其他Worker，但整体QPS会因随机间隔产生波动 -
on_start()：每个Worker进程只执行一次（不是每个用户），如果里面写了登录获取token，要注意token是否被多个用户复用导致服务端限流 -
@task(3)权重：仅在当前Worker内部生效，各Worker之间任务分布比例一致，但绝对请求数取决于各自分配到的用户数 -
host参数：必须显式指定，不能依赖Web UI填写——Worker启动时就读取该值，UI修改无效
性能影响点：
- 如果
on_start里做了耗时操作（如读大文件、解密密钥），会拖慢Worker初始化，导致“用户孵化延迟”，压测曲线前期平缓 -
wait_time设太小（如constant(0.1)），在高并发下可能让Worker CPU跑满，反而降低实际发包能力
压测数据失真的三个隐蔽信号，比错误率更值得盯紧
错误率0%不等于压测有效。真正要盯的是底层指标是否自洽：
- Master Web界面上
Total Requests数字增长缓慢，但Requests/s图表却有剧烈毛刺——说明Worker间心跳或数据上报不稳，大概率是网络抖动或ZeroMQ消息堆积 - 同一接口的
Median和95%ile响应时间差值突然拉大（比如从50ms/200ms变成50ms/2000ms），表明部分Worker开始丢协程或系统负载过载 - Worker进程的RSS内存持续上涨且不回收（
ps aux --sort=-%mem | head -5），大概率是脚本里用了全局缓存、没清理的session或循环引用，分布式下会放大泄漏速度
最常被忽略的一点：Locust默认用msgpack序列化传输数据，但如果你在on_start或task里传了不可序列化的对象（比如threading.Lock或自定义类实例），Worker不会报错，只会静默跳过该用户，导致实际并发数永远达不到设定值。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
