JMeter下载CSV文件时大小、内容与手动下载不一致问题排查

按优先级从高到低逐项核对即可定位问题：

• 先做请求一致性校验
  把Fiddler抓到的手动下载请求，和JMeter实际发出的请求逐字段对比，重点核对：
  • 所有请求头：尤其是Cookie/Authorization等鉴权字段、Referer、Accept、Accept-Encoding，缺任意一个服务端都可能返回错误提示页、非预期压缩格式的内容，而非目标CSV文件
  • 所有请求参数：包括URL路径、Query参数、POST报文体，手动下载时携带的时间戳、签名、导出筛选条件如果和JMeter配置不一致，返回的文件本身就会有差异
• 修正JMeter基础配置缺陷
  • 选中对应下载请求的HTTP采样器，将Implementation选项切换为HttpClient4，不要使用默认的Java实现——Java实现对分块传输、长连接的文件流支持存在已知问题，容易截断响应导致文件大小偏小
  • 打开HTTP请求默认值配置，不要全局强制设置响应编码为UTF-8，否则会将CSV文件流按文本规则转码，直接造成内容损坏、大小异常；如果站点使用压缩传输，在Compression配置项填入gzip, deflate, br和浏览器行为对齐
• 修正响应保存配置
  打开你使用的Save Responses to a file监听器，核对配置：
  • 取消勾选所有自动添加文件名前缀、后缀、时间戳的选项，避免找错实际生成的结果文件
  • 不要手动指定响应编码配置项，留空即可，强制指定编码会损坏二进制流内容
  • 不要开启仅保存成功/失败响应之外的特殊过滤规则，避免截断完整响应内容
• 快速验证定位
  给下载请求添加View Results Tree监听器，单次运行请求后直接查看响应数据：
  1. 先对比响应头中的Content-Length字段和Fiddler抓到的手动下载响应头字段值，如果数值不一致，说明请求本身不符合服务端要求，返回的不是目标文件
  2. 如果Content-Length一致，查看响应内容开头：如果是HTML标签、错误提示文本，说明鉴权失效/参数错误；如果是乱码，说明存在转码配置错误
  3. 直接从监听器读取的响应长度和实际手动下载长度一致时，再用Save Responses to a file导出文件即可，不要用监听器页面手动另存的文件做对比，手动另存会引入额外编码问题

避坑提示：如果下载接口有防爬校验，还要核对JMeter请求的顺序、Cookie携带链路是否和浏览器操作一致，比如部分站点需要先访问导出按钮所在页面、拿到临时Cookie后才能请求下载接口，直接请求下载链接会被拦截返回错误页。

内容的提问来源于stack exchange，提问作者Ralph