ab验证Laravel接口吞吐量需先豁免CSRF、用127.0.0.1绕DNS、启用Keep-Alive；执行ab -n 2000 -c 100 -k http://127.0.0.1/api/test，重点关注Requests per second、Time per request（mean）和Failed requests三项指标。
用 ab 工具验证 Laravel 接口并发吞吐量，核心是绕过干扰项、聚焦真实接口性能。它不测全站，只测单点——适合上线前快速摸底或 CI 中轻量回归。
前置准备：让 Laravel 接口可压测
默认 Laravel 会拦截非浏览器请求（如 CSRF、Session、中间件鉴权），需临时放宽：
- 在
app/Http/Middleware/VerifyCsrfToken.php的$except数组中加入测试路由，例如'/api/test' - 若接口依赖登录态，不建议用 session 模拟，改用无状态方式：比如临时关闭 auth 中间件，或使用 API token（如
Authorization: Bearer xxx）并确保该 token 在测试期间有效 - 确认接口能被直接访问：用
curl -I http://127.0.0.1:8000/api/test验证返回200，避免 DNS 或 IPv6 解析拖慢结果
执行压测：ab 命令关键参数组合
命令结构要简洁明确，避免隐式行为影响结果：
Laravel Cloud
下载
Laravel Cloud（cloud.laravel.com）。此技能用于处理所有 Laravel Cloud 请求，包括搜索和读取数据。只要任务涉及 Laravel Cloud，即使用此技能。
- 用
127.0.0.1替代localhost，跳过 IPv6 查找和 DNS 解析开销 - 加
-k启用 Keep-Alive，减少 TCP 握手损耗，更贴近真实复用场景 - 基础命令示例：
ab -n 2000 -c 100 -k http://127.0.0.1:8000/api/test - 带认证的 GET：
ab -n 500 -c 50 -H "Authorization: Bearer abc123" http://127.0.0.1:8000/api/user - POST 请求需准备数据文件（如
post.json），再配合-p和-T：ab -n 300 -c 30 -p post.json -T "application/json" http://127.0.0.1:8000/api/login
结果解读：盯住三个硬指标
ab 输出繁杂，只需关注以下三项即可判断瓶颈：
- Requests per second：即 QPS，数值越高说明单位时间处理能力越强；持续加压时若 QPS 不升反降，说明已达性能拐点
-
Time per request（mean）：用户平均等待时间，注意区分“across all concurrent requests”那一行——它是真正服务端平均耗时，等于
1 / QPS -
Failed requests：非零值需警惕，常见原因包括超时（
-s默认 30 秒）、连接拒绝（Linux 文件描述符不足）、或 Laravel 报错（如 DB 连接池满、内存溢出）
注意事项：ab 的能力边界
ab 是单 URL、无状态、线性请求工具，不适合以下场景：
- 需要维持登录态并执行多步操作（如先 POST 登录，再用 Cookie 请求资源）——此时应换 JMeter 或 k6
- 测试 HTTPS 且目标域名启用 SNI（ab 旧版本不支持），建议升级到 Apache 2.4.49+ 或改用其他工具
- 并发 >1000 时，Linux 默认 open files 限制（1024）会成为瓶颈，运行前执行
ulimit -n 15000 - 不反映前端资源加载、JS 执行、网络延迟等真实用户体验，仅衡量后端接口吞吐与延时
