压测 index.html 本身无意义，真正需测试的是 Web 服务器对高频 GET 请求的响应能力及重定向、鉴权等中间件行为；单纯 curl 只验证单次可达性，无法模拟并发、Cookie、重定向等真实场景；JMeter 需禁用自动重定向、添加 Cookie 管理器、合理设置 ramp-up 并校验响应码；http_load/wrk 更轻量，适合快速验证匿名首屏承载力；关键在明确压测目标：是服务器并发能力、登录流程吞吐，还是 CDN 缓存效果。
index.html 页面本身没意义——它只是个静态资源，真正要测的是背后 Web 服务器（如 Nginx、Apache、IIS）对高频 GET 请求的响应能力，以及是否因重定向、会话拦截或前端逻辑引发连锁问题。
比如你用浏览器访问 index.html，系统却跳转到 login.html，说明有中间件（如 Spring Security、Nginx auth_basic、或前端路由守卫）在干预。这种重定向不是页面的问题，而是服务端策略或鉴权逻辑的体现。压力测试时若忽略这点，测出来的“失败率高”“响应慢”，实际反映的是登录网关或 Session 初始化瓶颈，而非 HTML 文件本身。
为什么不能只 curl index.html 就算压测？
单纯用 curl http://host/index.html 只验证单次可达性，不模拟真实并发行为。压力测试必须考虑：
- 连接复用（HTTP/1.1 keep-alive vs HTTP/2 multiplexing）是否开启
- 是否携带必要
Cookie或Authorization头（否则触发重定向） - 响应体大小和传输耗时是否受带宽或 gzip 压缩影响
- 服务器是否对未登录请求返回 302 跳转，导致每个请求多一次往返
用 jmeter 压测 index.html 的关键配置点
如果你用 JMeter，别直接加一个 HTTP Request 就跑。常见翻车点：
- 没禁用
Redirect Automatically：默认勾选，会让 JMeter 自动跟随 302，掩盖真实跳转开销；应取消勾选，配合View Results Tree观察原始响应码 - 线程组里没设
HTTP Cookie Manager：若登录态依赖 Cookie，不加这个组件，每次请求都是“新用户”，必然被踢去 login - Ramp-up period 设为 0：100 个线程瞬间打过去，可能触发服务器限流或 TIME_WAIT 爆满，结果全是 connect timeout，而非业务瓶颈
- 没加
Response Assertion校验状态码：比如期望 200 却收到 302 或 503，不设断言就当成功，报告失真
更轻量的替代方案：http_load 或 wrk
如果只是快速验证静态页承载力，http_load 比 JMeter 启动快、资源占用低：
http_load -parallel 100 -seconds 30 urls.txt
其中 urls.txt 内容只有一行：http://your-server/index.html。注意：
立即学习“前端免费学习笔记（深入）”；
- 它不处理重定向，返回 302 就算失败，正好暴露登录拦截逻辑
- 不维护 Cookie，适合测“匿名访客首屏”场景
- 输出里重点关注
non-2xx: X和avg response time，而不是吞吐数字
index.html 只是一个入口标记，背后链路可能横跨 DNS、CDN、WAF、负载均衡、应用服务器、甚至前端 SSG 构建缓存。压测前，先确认你要盯住哪一环。 
