企业官网建设流程全解析

前几天同事来找我，说项目上线前得做一轮接口压测，Jmeter的图形界面在他那台Windows办公机上越跑越卡，压测机自己先躺平了。我扔给他一个Apache自带的ab（ApacheBench），五分钟跑完一轮，十分钟把报告发到了群里。他回了一句：这玩意儿也太轻了吧。

确实，在Windows环境下做接口压力测试，很多人的第一反应就是装Jmeter或者买商业压测平台，反而忽略了ab这个自带的好东西。它不需要安装复杂的运行时环境，不需要写脚本，一个exe文件搞定一切。这篇文章我就把在Windows上从下载、调参、执行到读懂输出的完整链路拆开讲清楚，全程实操向，适合后端开发、测试工程师、运维同学，也适合那些只想快速验证接口能扛多大并发、不想折腾重型工具的团队。

1. 为什么在Windows上我推荐ab而不是其他压测工具

最开始我也没打算用ab，毕竟在性能测试圈子里它的名气没有Jmeter大。但实际对比下来，在Windows这个特定场景里，ab的优势相当明显。

先看Jmeter。它的图形界面是强项，但也是最大的短板——发起压测时，Jmeter自身的线程模型和GUI渲染会吃掉大量CPU和内存。我做过一次对比，本机8核16G的Windows，用Jmeter压200并发时，压测机CPU先飙到90%，接口还没怎么出汗，压测端先虚脱了。当然Jmeter可以开非GUI模式，配置麻烦不说，结果报表还是得拉回GUI看。

再看wrk，这是Linux平台上很优秀的压测工具，单线程就能打很高的并发，但在Windows上原生跑不了，要么装WSL，要么用Cygwin编译。WSL方式我试过，网络层绕一圈之后，压测数据会有偏差，而且WSL的TCP连接并发能力和原生Windows有明显差异。为了压测去折腾一套Linux子系统，对很多Windows开发者来说成本偏高。

ab则是Apache基金会自带的性能测试工具，在Windows下就是一个ab.exe。它支持的并发模型虽然不像wrk那样极致，但对绝大多数HTTP接口的压测需求来说完全够用。最关键的是它足够简单：命令一行，结果清晰，几乎没有学习曲线。很多人觉得ab只能压GET、不能带Header，其实是个误解，后面我会专门讲怎么用它压POST和带鉴权头的接口。

当然ab也有明显的边界：它只能发HTTP/1.0和HTTP/1.1请求（默认HTTP/1.0，加-k参数走HTTP/1.1长连接），不支持HTTP/2；它没有图形报表，不会自动生成曲线图；它以单进程多线程方式运行，极端高并发下（比如单机压10万QPS）压测机本身会先成为瓶颈。但这些边界在实际项目中很少触到——日常接口压测，QPS量级一般就在几千到几万，ab完全扛得住。

一句话总结：Windows环境下，图省事、要快速拿到可信数据，ab是性价比最高的选择。

2. Windows下ab的下载、安装验证与第一个压测命令

很多教程默认你在Linux上装好了Apache，然后直接教参数，Windows用户卡在第一步就放弃了。这里把Windows环境下的完整流程走一遍。

2.1 下载安装：不需要完整安装Apache

ab.exe不需要单独发布，它随Apache一起分发。在Windows上你不需要把Apache安装成系统服务，只需要下载解压版，进到bin目录就能用。

推荐从Apache官网的Windows二进制分发页面下载，下载对应版本的zip压缩包后解压到任意目录（比如D:\tools\apache24），然后进入D:\tools\apache24\bin，exe就在里面。

需要注意一个坑：有些安装包是带SSL模块的完整版，解压后目录里会有好几层，不要被它唬住。你只需要找到ab.exe，它不依赖Apache的其他模块，单独拷出来放一个干净目录也照样能跑。

另外Windows安全中心或者第三方杀毒软件偶尔会误报Apache自带工具，遇到底下那种弹窗直接选择信任即可——Apache是开源项目，官方渠道下载的包安全性是有保障的。

2.2 验证环境：先确认ab能跑起来

打开cmd或者Windows Terminal，切到bin目录，执行：

ab -V

如果能输出版本信息，说明环境没问题。这里有个细节：Windows Terminal比旧版cmd好用得多，粘贴URL、查看长结果都不会乱，建议直接用Windows Terminal操作。

如果提示ab 不是内部或外部命令，大概率是当前目录没切对，或者你打开的是普通cmd且bin目录没加入PATH。我习惯直接把bin目录加到系统PATH环境变量里，这样不管在哪个目录下都能直接敲ab。

2.3 第一个压测命令：从最简单的请求开始

假设本机起了一个Spring Boot服务，端口8080，有一个/api/ping接口。先跑一个最基础的压测：

ab -n 100 -c 10 http://127.0.0.1:8080/api/ping

这行命令表示：总共发送100个请求，每次并发10个。

跑完屏幕上会出现一大堆指标，第一次看容易懵，我在第4节会把这堆数字逐个拆开讲。先说明一个容易踩的坑：Windows命令行里执行ab时，URL必须用双引号包起来，否则当URL带查询参数（比如?id=1&name=test）时，&会被cmd解释成命令分隔符，压测内容就完全错了。正确写法是：

ab -n 100 -c 10 "http://127.0.0.1:8080/api/user?id=1&name=test"

还有一个经常被搜到的报错值得单独提醒：执行网络工具时提示error opening file for writing: C:\Windows\System32\drivers\npf.sys，这个错误不是ab弹出来的，是你的抓包工具在安装WinPcap/Npcap驱动时被杀毒拦截了，跟ab没有任何关系。看到这个报错，去装Npcap驱动或者检查驱动签名就行，别在ab上浪费时间排查。

2.4 压测前先确认的事

正式压测前，花十秒钟确认一下你要压的接口是不是走HTTP。如果接口是HTTPS，ab命令一样可以用，只把URL换成https://开头即可，ab会自动进行TLS握手。不过Windows下如果目标证书是自签名的，ab默认会报SSL验证错误，这时需要加参数跳过验证：

ab -n 100 -c 10 -k -Z "https://127.0.0.1:8443/api/ping"

-Z的作用是启用TLS/SSL并忽略证书校验，实测在Windows上对自签名证书的测试环境很管用。

3. ab核心参数详解：并发数、请求总数、长连接和Header处理

网上很多教程把ab参数列一个表格就完了，但实际压测时怎么选参数、为什么这么选，才是关键。这里不打算堆砌所有参数，而是把最常用的几个讲透，让你拿到任何一个接口都能设计出合理的压测命令。

3.1 -n和-c：请求总数与并发数的组合逻辑

-n是本次压测的总请求数，-c是同时发起的连接数。这两个值不是随手写的，它们直接决定了压测的持续时间和结果的稳定性。

我在实际压测中最常用的配置是-n 10000 -c 100，即100个并发请求一直打，直到累计完成10000个请求为止。为什么要1万起步？因为如果总请求数太少（比如100个），样本太小，平均值很容易受网络抖动影响，结果没有统计意义。1万请求在100并发下通常也就跑几十秒，时间成本完全可接受。

更要理解的是-c和-n的比例关系。同样是1000个请求，-c 100 -n 1000和-c 1000 -n 1000的结果天差地别。后者意味着第一波1000个连接同时打开，对服务器来说相当于瞬间打进来的流量洪峰，很多服务直接在这个场景下暴露出连接池配置不足的问题。如果是做容量评估，我建议从小到大递增并发，比如50、100、200、500，每个档位跑一轮，观察QPS和响应时间的变化趋势，而不是一上来就压极限——一上来就压极限的后果往往是服务直接崩了，你根本分不清是代码bug还是过载保护生效。

3.2 -k参数：Windows下很容易忽略的长连接开关

ab默认使用HTTP/1.0协议，每次请求都新建一个TCP连接，请求完立刻断开。这在压测时会带来两个问题：一是每次请求都多一次TCP握手和四次挥手的过程，压测机本地的端口和系统资源被大量消耗；二是不符合现代应用的真实使用习惯，现在几乎没有前端会用HTTP/1.0短连接去刷接口，都是HTTP/1.1长连接。

加上-k参数后，ab会启用HTTP/1.1的Keep-Alive机制，多个请求复用同一个TCP连接，更接近真实生产环境的连接模型。实测差异非常明显：同一个接口，不加-k时QPS可能只有500，加了之后能跑到2000，这不代表服务器变快了，而是压测方式更合理了。在Windows上特别容易忽略这一点，因为Windows默认的TCP动态端口范围有限（默认从49152开始，只剩约16000个端口），短连接模式下并发一高，压测机自己先报端口耗尽。

建议默认压测命令里都带上-k，除非你压的接口本身明确就是短连接场景（比如某些网关限制Keep-Alive），那样才去掉-k。

3.3 -H、-p、-T：给压测请求带上Header和Body

很多人以为ab只能压GET接口，这是对它最大的误解。在Windows下压测带鉴权Token的接口，或者压POST的JSON接口，一样能实现。

先说要带自定义请求头的情况。比如很多项目的前端接口都要在Header里带上Authorization: Bearer xxx这种Token，ab直接用-H指定：

ab -n 1000 -c 50 -k -H "Authorization: Bearer eyJhbGciOi..." "http://127.0.0.1:8080/api/data"

注意-H如果出现多个Header，需要写多个-H参数，不能像其他Linux工具那样拼在一个引号里用分号分隔。实测在Windows下写成-H "Header1: x" -H "Header2: y"这样才稳定生效。

再说不带查询参数、而是要发JSON Body的POST接口。ab的做法是把请求体写到一个文件里，然后通过-p指定这个文件，同时用-T声明Content-Type：

ab -n 1000 -c 50 -k -p body.json -T application/json "http://127.0.0.1:8080/api/user/query"

其中body.json就是POST请求体内容，比如：

{"userId": "10086", "pageSize": 20}

这里有一个Windows特定的坑：body.json如果使用记事本编辑且保存为带BOM的UTF-8编码，ab在Windows下解析时可能把BOM字符一起发出去，导致服务端反序列化报错。建议用VSCode这类工具保存为无BOM的UTF-8格式，或者直接保存成ASCII。另外文件内容不要换行，实测带换行的请求体会导致一些严格校验的服务端直接返回400。

压测Web表单类型的接口时，body.json内容改成URL编码格式，比如name=test&age=18，-T改成application/x-www-form-urlencoded即可。

3.4 Cookie和基础认证：-C与-A

有些接口用Cookie做登录态，ab提供了-C参数：

ab -n 500 -c 20 -k -C "sessionId=abc123def456" "http://127.0.0.1:8080/api/order/list"

写法上-C只需要写key=value部分，ab会自动拼成Cookie: sessionId=abc123def456头发出去。如果Cookie有多个字段，就多写几个-C参数。

如果接口用的是HTTP Basic认证，可以用-A直接传用户名和密码（中间用冒号隔开，Windows cmd下建议用双引号包起来）：

ab -n 500 -c 20 -A "admin:123456" "http://127.0.0.1:8080/api/admin/info"

带鉴权后的压测结果才接近真实业务场景，因为很多接口在无Token时走的是快速失败逻辑，压根没进业务处理链路，测出来的数据完全不能反映生产性能。

3.5 其他值得一提的参数

• -t：压测时长（秒），和-n二选一使用。接口压力测试不能只关注固定请求数模式，有些场景需要按固定时长持续打压。比如ab -t 60 -c 100 -k http://...表示压60秒，期间尽可能多地发请求。
• -r：遇到连接错误时不退出。不加这个参数时，ab遇到一个Connection reset就整体退出，浪费一锅压测。实测压后端过载场景时，不加-r经常一开局就中断，数据丢失；加上之后ab会继续跑完整个压测周期。
• -v 4：把每个请求的响应头打印出来。这个主要用于调试阶段，确认请求头确实带上了、服务端真的返回了预期状态码。压测发起前先-n 1 -v 4跑一次，等于免费送了一个curl。
• -w：以HTML表格形式输出结果，可以重定向到文件生成压测报告页。虽然不是复杂图表，但直接拿给非技术人员看比纯文本直观得多。

4. 读懂ab输出：每个指标背后的真实含义

ab跑完之后输出的那堆英文指标，说实话信息密度很高，但很多人扫一眼只记住了QPS数字就结束了，这是比较可惜的。每个数字背后都对应着系统某一侧的运行状况，我把它们拆开逐项讲清楚。

4.1 前四行与请求完成情况

先看输出开头的部分：

Server Software: nginx/1.24.0 Server Hostname: 127.0.0.1 Server Port: 8080 Document Path: /api/ping Document Length: 24 bytes

这些描述的是被压测服务的基本信息。Server Software是服务器软件的名称和版本，Document Length是响应体的大小。如果Document Length在不同压测轮次中差别很大，说明响应内容不是固定长度的（比如带动态数据），这会直接干扰后续传输速率的判断。

再看这行：

Complete requests: 10000 Failed requests: 0

Complete requests是成功完成全部请求的数量，Failed requests则代表失败数量。这里有个必须明确的概念：ab判断"失败"的条件是什么？用户经常以为只要HTTP状态码是200就不算失败，这个概念在ab里不一定成立。ab把以下情况都算作失败：连接建立失败、请求发送中断、接收响应时连接被重置、socket超时。HTTP返回500也算不算失败？——这部分ab不会自动算失败，因为从传输层看请求是"完成"的，实际业务错误要看响应体来判断。这正好暴露了ab的一个局限：它做不到业务断言。压测的接口如果只返回200但JSON里code:500表示业务失败，ab是看不出来的，只能靠你自己写脚本去捞响应体分析。

4.2 响应时间和吞吐量：最核心的两个指标

先看Requests per second：

Requests per second: 2451.30 [#/sec] (mean)

这个是QPS，每秒处理的请求数，也是绝大多数人最关心的指标。它计算方式是总请求数除以总耗时，反映的是平均吞吐量。但要注意，QPS是"结果"不是"原因"——系统QPS上不去，可能是代码慢、数据库慢、网络慢、或者并发本身就不够。单独看QPS没有任何意义，必须结合响应时间和并发数一起看。

再往下是两行Time per request，非常容易出现理解偏差：

Time per request: 40.790 [ms] (mean) Time per request: 0.408 [ms] (mean, across all concurrent requests)

第一行数字是"平均每个请求的响应时间"，这个好理解。第二行数字很多人以为是笔误或者重复打印，其实它的算法是把总跑批时间除以总请求数——可以把它粗略理解成"系统服务端的整体吞吐视角下，平均每个请求摊到的服务时间"。举个例子：100并发，总耗时4秒，10000个请求，第一个式子算出来的是用户实际体验到的平均等待时间（约408ms），第二个式子算出来的是把4秒总耗时摊到10000个请求上的结果（约0.4ms）。两个数字结合着看，前者反映用户体验，后者反映系统吞吐成本。

接下来看连接耗时：

Connection Times (ms) min mean[+/-sd] median max Connect: 0 1 2.1 0 20 Processing: 1 38 15.8 35 160 Waiting: 0 35 14.9 32 155 Total: 1 39 16.2 36 168

Connect是TCP三次握手耗时，Processing是服务器接收请求到响应完成的时间（包含业务处理），Waiting是发出请求后到收到响应第一个字节的等待时间（不包含响应体下载时间），Total是完整请求总耗时。这里我一般主要看两个点：一是Connect的mean如果明显偏大（比如几十毫秒），说明压测机和目标机器之间的网络链路有问题，或者压测机本地端口资源吃紧；二是Waiting如果远大于Processing，说明服务端在业务处理之前就已经有排队等待，也就是服务端的线程池或连接池已经打满了——这时候再往上加并发，QPS基本不会再提升。

4.3 响应时间分布：TP值对性能评估的意义

ab结果最后一行是这个：

Percentage of the requests served within a certain time (ms) 50% 36 66% 40 75% 43 80% 45 90% 55 95% 70 98% 105 99% 125 100% 168 (longest request)

这组数据是响应时间的百分位分布，也就是常说的TP50、TP90、TP99。50%的请求在36ms内完成，90%的请求在55ms内完成，99%的请求在125ms内完成。这里的关键判断逻辑是：只看平均响应时间很容易被"少数慢请求拉高平均值"骗过去，但TP99能暴露出真实的尾延迟问题。

我在实际工作中遇到过一个很典型的场景：接口平均响应80ms，看起来完全正常，但看TP99发现到了800ms。结合Connection Times里的max值，定位到是数据库连接池在峰值时有部分请求排队等待连接。如果当时只看平均值，这个问题会被彻底隐藏掉——这也是ab虽然老，但这套百分位统计逻辑至今仍是性能报告标配的原因。

4.4 Transfer rate与其他辅助指标

Transfer rate: 92.27 [Kbytes/sec] received

Transfer rate是网络传输速率，包括请求头和响应头的字节，不只是响应体。如果压测的接口返回数据特别大（比如一个十几MB的列表），这个指标会成为瓶颈，此时QPS上不去不代表计算慢，而是带宽或者序列化/反序列化的IO占了主导。遇到这种情况，就要考虑压测时是否应该减少响应体数据量，或者用更贴近生产环境的真实数据来压。

还有两个辅助指标：

Total transferred: 11852000 bytes HTML transferred: 11566000 bytes

HTML transferred是响应体总字节数，Total transferred则包含Header。这两个值之间的差距如果异常大，说明响应Header特别大——比如Cookie带得太多，或者自定义Header字段过多，这在网关类接口上很常见，也是隐性优化点。

5. 实战演示：在Windows上压测一个带鉴权的POST接口

前面讲的都是点状知识点，这一节把它们串起来，用一个完整案例把从设计到分析的流程走一遍。场景设定：内网环境，Windows下压测一个FastDFS上传后的JSON查询接口/api/order/query，它接受POST请求，请求体是JSON，要求Header带Bearer Token。

5.1 事前准备：先看清楚接口长什么样

我习惯先用一个最小请求确认接口的行为。用-n 1、-v 4发一个调试请求，看返回头和Body：

ab -n 1 -v 4 -H "Authorization: Bearer token123456" -H "Content-Type: application/json" -p body.json -T application/json "http://192.168.1.101:8080/api/order/query"

-v 4会输出完整的请求头和响应头。执行后确认三个关键信息：请求头里Authorization确实带上了；返回的HTTP状态码是200；响应体长度符合预期。如果这一步返回401或者404，说明请求本身都没发对，后面压测也是白压。

5.2 设计压测参数：从单请求到并发阶梯

确认接口无误后，我建议按如下阶梯设计：

每一轮都带上-k、-r和完全相同的Header，保证只有并发数在变。比如中并发这一轮：

ab -n 5000 -c 50 -k -r -H "Authorization: Bearer token123456" -H "Content-Type: application/json" -p body.json -T application/json "http://192.168.1.101:8080/api/order/query"

这里在Windows上最容易翻车的点是：命令太长时，cmd会把行的显示宽度撑爆或者被自动换行打断。建议用Windows Terminal，命令直接换行后按^符号续行（cmd的续行符是^），但实测在中文Windows上^后面不能有空格，否则会解析失败。为了减少这种低级问题，我都是把一条完整命令直接复制粘贴成一行执行，虽然看起来长，但省心。

5.3 结果解读：一次典型的容量评估分析

假设100并发这一轮跑出来的关键指标如下：

Complete requests: 10000 Failed requests: 8 Requests per second: 2180.50 [#/sec] (mean) Time per request: 45.849 [ms] (mean) Time per request: 0.458 [ms] (mean, across all concurrent requests) Percentage of the requests served within a certain time (ms) 50% 42 90% 70 99% 115 100% 245

怎么解读这组数据？

第一，Failed requests: 8，虽然不是0，但占比不到千分之一，结合-r参数的效果（出错继续跑完），可以判断这8个失败属于偶发连接中断，不影响整体结论。但如果Failed数量超过1%，就得深挖一下是压测机端口耗尽还是服务端出现了连接拒绝，不能顺手带过。

第二，QPS约2180，TP99为115ms，说明在100并发下，系统能稳定支撑约2000QPS，且99%的请求在115ms内完成。这个数据对多数内部系统来说已经够用了。

第三，对比50并发那一轮的数据，假如50并发时QPS约2100，TP99约80ms；100并发时QPS约2180，TP99约115ms。前者QPS增幅很小而响应时间明显上涨，说明系统的吞吐瓶颈已经出现。这时候继续加并发没有意义，因为QPS不会再跟着涨，只会徒增响应时延。真正的容量上限大概就在100并发附近，这就是这一轮压测的核心结论。

5.4 当压测机自己先扛不住时怎么办

在上述压测过程中，如果你的CPU观察发现ab进程已经占满了一个核心，同时服务器端CPU还没满，QPS却不再上涨，那很可能是ab自身的线程模型到了瓶颈。ab是单进程多线程模型，在Windows上受制于线程调度开销，极限并发能力大约是Linux下的一半左右。

遇到这种情况，实测比较好用的方案是开多路ab并发执行，把总并发分摊到两个压测机上。比如想要200并发，就开两个终端，各跑-c 100，压同一个接口。不过这样一来结果文件需要自己汇总，ab的-wHTML输出刚好能拿来做单路归档，再自己合并统计。如果你频繁遇到压测机先瓶颈的情况，那说明项目已经进入需要专业压测平台的阶段，ab只是帮你撑过了前期的快速验证期。

6. Windows环境下高并发压测的进阶排障与调优

Windows上压测时容易遇到一些独立于应用本身的系统级问题，这些坑不填掉，压测结果很难看，但问题根本不在服务端。下面几个是我在Windows上多次踩过、也帮同事排查过的典型案例。

6.1 端口耗尽：压测机自身的隐蔽瓶颈

Windows系统默认的动态端口范围是从49152到65535，也就是大约16000个端口。如果不用-k长连接，每发一个请求就新建一个TCP连接，压完后端口进入TIME_WAIT状态，要等约2分钟才能释放。并发500时，几秒种就能把所有动态端口耗尽，随后qps断崖下跌，报错里全是apr_socket_connect: 由于目标计算机积极拒绝，无法连接——连请求还没进到服务端就被压测机的TCP栈拒绝了。

解决方案有两个：一是所有压测命令都带-k，用长连接复用端口，这是根治方案；二是用管理员权限执行下面两条命令，扩大动态端口范围：

netsh int ipv4 set dynamicport tcp start=10000 num=40000 netsh int ipv4 set dynamicport udp start=10000 num=40000

修改后建议重启系统（实测部分网络服务需要重启内核参数才完全生效），然后可以用netstat -ano | findstr TIME_WAIT看端口状态确认。

6.2 杀毒软件与防火墙对延迟数据的干扰

Windows Defender和第三方杀软在压测中会周期性地扫描新建文件、监控网络连接。这种监控会让压测结果的延迟出现间歇性尖峰，表现为TP99突然飙高、然后下一轮又恢复正常。排查方法很简单：压测时观察CPU，如果Defender进程（MsMpEng.exe）的CPU占用出现周期性起伏，那就是它在干扰。

压测前把压测目录、ab.exe加白名单，把5000~9999的临时端口设置为防火墙允许。注意不要为了压测关掉整个Windows Defender，我见过同事关掉杀软压测，测完忘了开，第二天公司安全软件直接弹警报。只加白名单就足够。

6.3 如何判断瓶颈在应用还是基础设施

压测结果如果显示CPU 100%但QPS不达标，需要先分清楚瓶颈在哪一层。我惯用的方法：一次压测中同时打开三个性能监视器窗口，分别盯服务端CPU、服务端内存、以及数据库连接数。如果服务端CPU没满、数据库连接数打满，那就是连接池配置小了；如果服务端CPU满了、单核打平，先看代码里有没有大量同步阻塞；如果服务端CPU满、但GC日志里长停顿频繁，那内存分配和对象回收又成了主要矛盾。

ab自己不会帮你区分这些，但它的并发结果曲线能给出一个判断方向：并发从50升到200，QPS持续线性增长，说明还没到瓶颈；QPS增长明显放缓、响应时间线性拉长，说明某个共享资源（连接池/线程池/数据库锁/带宽）即将耗尽；QPS直接掉头向下，说明已经发生了严重的资源竞争，比如内存换页或GC风暴。

6.4 压测过程数据留档

最后说一个我自己的习惯。每一轮压测的命令、结果、系统监控数据，我都会用下面这个格式记录到文本文件里：

ab -n 10000 -c 100 -k -r -H "Authorization: Bearer token123456" -H "Content-Type: application/json" -p body.json -T application/json "http://192.168.1.101:8080/api/order/query" > result_100c_10000n.txt 2>&1

Windows cmd下>重定向会把输出写进文件，2>&1把错误信息也一并归入。这样一轮压测的全部信息都在一个文件里，后面出报告时直接粘数据，不用凭印象回填。ab本身不带时间戳，所以我会在文件名里就标明场景和轮次，比如result_c100_n10000_baseline.txt、result_c100_n10000_connectionpool_50.txt，这样横向对比时一眼就能看出是哪一轮。

这些坑单看都不大，但在Windows上压测时一旦撞上，轻则数据失真，重则压测机直接把服务端打出误判。提前把它们排除掉，ab在Windows上的可用性完全不输在Linux上的表现。