火车采集器采集 GET JSON 接口为空的排查记录：Reqable 对比定位 Brotli 压缩与 JSON 规则问题

标题

火车采集器采集 JSON 接口为空的排查记录：Reqable 对比定位 Brotli 压缩与 JSON 规则问题

内容

这次采集的是某转门店列表接口：

https://app.zz.com/zzopen/store_mobile_server/getStoreListOfUserV2?latitude=22.614241342568857&longitude=114.03709154956078&importStreamType=app_nearby

接口返回的是标准 JSON，核心数据在：

respData

单个门店字段包括：

storeId
storeName
detailAddress
longitude
latitude
businessHour
businessFlag
distanceDesc
cityName
pic

最开始在火车采集器里使用 JSON 提取时，storeId、storeName 都为空。通过 Reqable 对比原始请求和火车采集器请求，发现火车采集器发出的请求其实是成功的，接口返回状态码是 200，响应内容里也有完整的 respData 门店数组。

所以问题不在接口，也不在 Cookie，而是在火车采集器的内容解析环节。

第一个问题是请求头里的压缩格式。火车采集器请求中带了：

Accept-Encoding: gzip,deflate,gzip, deflate, br

服务端返回：

Content-Encoding: br

也就是 Brotli 压缩。Reqable 和 HTTP 查看工具能正常显示解压后的 JSON，但火车采集器的内容规则里可能没有正确把 Brotli 解压后的内容交给 JSON 提取器，导致 $.respCode 都取不到。

解决方式是删除 Accept-Encoding，或者改成：

Accept-Encoding: gzip, deflate

重点是不要带 br。

第二个问题是 JSON 表达式写法。错误写法类似：

respData[0][storeId]

火车采集器 JSON 提取应使用 $ 开头的路径，例如测试第一条数据：

$.respCode
$.respData[0].storeId
$.respData[0].storeName

预期结果：

respCode = 0
storeId = 312026941821953
storeName = 龙华缤果空间店

确认单条能取到以后，再改成批量提取：

$.respData[*].storeId
$.respData[*].storeName
$.respData[*].detailAddress
$.respData[*].longitude
$.respData[*].latitude
$.respData[*].businessHour
$.respData[*].businessFlag
$.respData[*].distanceDesc
$.respData[*].cityName
$.respData[*].pic

并勾选“循环匹配”。

这次排查的关键结论是：当 JSON 采集为空时，不要只盯着表达式。先用 Reqable 对比请求和响应，确认接口是否真的返回了数据；再测试 $.respCode 这种最简单路径。如果根节点都取不到，优先检查响应压缩、编码、源码来源，而不是继续改字段规则。

最终问题点总结：

1. 接口本身正常，火车采集器请求也成功。
2. Reqable 记录证明响应里有完整 respData。
3. 火车采集器 JSON 提取为空，主要是内容解析问题。
4. Accept-Encoding 带 br 会导致 Brotli 响应，可能影响火车采集器 JSON 提取。
5. JSON 表达式必须使用 $.respData[0].storeId 或 $.respData[*].storeId。
6. 先测试 $.respCode，再测试第一条，再做循环匹配。

采集接口时还要注意：Cookie、csrf-token 等字段可能包含登录态，不建议公开发布。