autocannon生成的HTML报告不能被CI直接用作门禁依据，必须使用--output参数输出JSON格式（如autocannon -c 100 -d 30s https://api.example.com --output report.json），再通过jq等工具提取latency.p99、requests.average、errors等字段进行阈值校验，未达标时显式exit 1触发CI失败阻断。
autocannon生成的HTML报告怎么被CI识别为门禁依据
CI本身不解析HTML，所以直接把autocannon输出的HTML丢进流水线，它只会当成静态文件存档，完全不会触发阻断逻辑。关键在于提取指标并转成机器可读格式。
- 必须用
--output参数指定JSON输出（如autocannon -c 100 -d 30s https://api.example.com --output report.json），而不是依赖默认HTML - HTML报告只是给人工看的副产品；真正用于门禁的是JSON里
latency.p99、requests.average、errors这些字段 - 若硬要用HTML，得额外加解析步骤（如用
jq或Node脚本从HTML中扒出<td>P99: 124ms</td>），但极易因HTML结构微调而崩溃，不推荐
如何用autocannon JSON结果实现硬性阻断
光有JSON还不够，得让CI根据数值做判断并主动失败。Jenkins或GitHub Actions里不能只跑命令，必须写校验逻辑。
- 在
sh步骤里用jq提取关键值，例如：jq '.latency.p99' report.json | sed 's/[^0-9.]//g' - 设阈值后用
if判断：如果$(jq '.latency.p99' report.json) > 150就exit 1 - GitLab CI可直接用
rules结合script返回码；Jenkins则需确保sh步骤失败时整个stage标为FAILURE，不能被ignoreFailure true绕过 - 注意
autocannon自身失败（如目标不可达）会返回非零码，但性能超标默认仍返回0——这是最常踩的坑，必须显式校验
为什么用autocannon不用JMeter做门禁
不是JMeter不行，而是它在门禁场景下天然有延迟和重量级问题。
-
autocannon启动快（毫秒级）、资源占用低（单进程多连接），适合嵌入短周期CI流程；jmeter需JVM预热、脚本编译，冷启动常超30秒 -
autocannon原生支持--warmup参数，能自动跳过前5秒抖动数据，避免误判；JMeter得手动配Timer+Logic Controller，配置复杂度高一倍 - CI环境通常无GUI、少内存，
autocannon的轻量Node.js依赖比JMeter的Java堆内存更易容器化部署 - 但反过来说：如果需要复杂事务链路（如登录→下单→支付→回调），
autocannon靠requests数组拼接容易出状态紊乱，这时JMeter或k6更稳
动态阈值怎么写进CI脚本而不硬编码
把150这种数字写死在脚本里，等于放弃动态能力。真实项目里阈值得随环境、服务、甚至PR分支变化。
立即学习“前端免费学习笔记（深入）”；
- 用环境变量传参：
autocannon -c $CONCURRENCY -d $DURATIONS $TARGET_URL，再在CI配置里按环境设CONCURRENCY=50（测试环境）vsCONCURRENCY=500（预发） - 从配置中心拉取：比如用
curl http://config-service/autocannon/thresholds?service=auth获取当前服务的P99阈值，再注入到校验逻辑 - 分支策略：对
main分支用严苛阈值（P99≤100ms），feature/*分支放宽到≤200ms，用$CI_COMMIT_BRANCH判断 - 注意所有外部依赖（如config service）必须设超时和fallback，否则网络抖动会导致门禁误挂
动态门禁最难的不是写脚本，而是让阈值变更本身也被版本化和审计——今天调低了P99，得知道是谁、为什么、影响哪些接口，否则很快就会变成没人敢动的黑盒规则。
