应使用ab、wrk或Locust等外部工具进行压力测试，而非PHP脚本；ab适合单接口吞吐摸底，需加-k和合理-c值；wrk支持高并发与长连接；Locust用于模拟真实用户行为流。
别学“用 PHP 写压测脚本”——它既测不准，又容易误导你对真实瓶颈的判断。PHP 本身不是压测工具，而是被测对象；真正有效的压力测试，必须用外部工具发起并发请求，同时配合 PHP 内部埋点观察执行细节。
ab 命令怎么跑出有效数据
ab 是最快上手的工具，但默认参数几乎必然测偏。它只适合单接口吞吐摸底，不是业务链路验证工具。
- 必须加
-k：否则每次请求重建 TCP 连接，测的是网络握手开销，不是 PHP 处理能力 -
-c值不能瞎设：若 PHP-FPM 的pm.max_children = 50，却用ab -c 200，你会看到大量 503 和排队延迟，这不是代码慢，是进程池满了 - 别信
Failed requests: 0：返回 200 不代表业务成功，比如下单接口可能重复扣库存，得靠日志或响应体断言验证 - POST 测试要配全：用
-p data.json -T "application/json"，否则后端收不到 body
wrk 为什么比 ab 更接近真实负载
ab 是单线程阻塞模型，wrk 是多线程 + 异步 I/O，单机就能打出更高并发，且连接复用更真实。
-
-t建议设为 CPU 核心数（如-t 4），-c才是总连接数（如-c 400），二者不相等 - 默认启用 keep-alive，若后端未调优，
pm.queue_length会暴涨，此时看Time per request (mean)没意义，得查 FPM 状态页 - 用
-s script.lua注入动态参数：比如每次带不同user_id，避免被 OPcache 或 Redis 缓存命中干扰结果 - 压 HTTPS 时若报证书错误，临时加
--insecure，但生产环境必须关掉
PHP 代码里必须加什么才能看清瓶颈
光靠外部工具打，你只能看到“接口慢”，但不知道慢在哪。PHP 脚本内部得有可观测性支撑。
立即学习“PHP免费学习笔记（深入）”；
- 在入口加
microtime(true)记录开始时间，响应前再算一次，写进 error_log 或结构化日志 - 开启
slowlog：配置request_slowlog_timeout = 1s，让 FPM 把超时请求的完整调用栈打出来 - 用
opcache_get_status()定期采样，确认脚本是否真被缓存、命中率是否稳定 - 数据库查询前后记时，和慢查询日志交叉比对；不要只信
mysql_query()返回快，要看实际执行耗时
Locust 什么时候该上，什么时候不该上
Locust 不是“更高级的 ab”，它是为模拟用户行为流设计的。用错场景，反而掩盖真实问题。
- 适合测完整链路：比如先
POST /login拿 token，再GET /order?token=xxx，自动维持 session - 必须写
@task分支逻辑：比如 70% 用户查订单，20% 提交订单，10% 退出登录，否则还是单点压测 - 别直接设
--users 5000：先从 100 开始，每 5 秒加 50（--spawn-rate 50），观察 QPS 和错误率拐点 - 它不替代 ab/wrk：Locust 启动慢、资源占用高，日常回归还是用 ab 快速过一遍核心接口
最容易被忽略的一点：所有压测必须重置环境。每次跑完，清 Redis、清 OPcache、重启 FPM、清 MySQL 查询缓存——否则第二次的结果，根本不可比。
