Node.js 中使用 fetch 请求 API 与浏览器行为存在差异，导致返回CSV表头异常的排查咨询

以下排查点全部匹配你当前已经验证过的场景特征，不需要重复做已经排除过的Cookie、JWT结构、认证鉴权类的测试：

• 逐字节对比两个场景下拿到的接口完整响应差异
  你目前只对比了两个JWT的可视结构，实际上服务端返回拿token接口的响应，除了你提取的token-for-campaign-results字段之外，可能还有隐藏的关联字段（比如导出类型标识、文件权限范围）被你忽略了。把Node.js请求拿到的全量JSON响应，和API测试工具拿到的同接口响应做逐字段diff，哪怕一个值的差异都可能是问题根源。另外两个示例token的JWT payload里，只有iat和exp两个时间戳有差异，说明服务端发token的逻辑没有校验到你当前请求应该对应的campaign类型，直接沿用了缓存的会话状态生成了结构相似但绑定错误的token。
• 对齐两类环境的请求头隐形差异
  不要觉得完全复制了Chrome的请求配置就和浏览器发的请求一致：Node.js内置fetch（以及undici、node-fetch类实现）的默认请求头有很多和浏览器/API测试工具不一致的隐形规则，比如自动剥离你手动设置的部分头、默认带上node标识的User-Agent、默认的Accept值和浏览器的差异。重点排查：
  • 有没有遗漏会触发服务端返回分支的请求头，比如Accept: application/json、指定语言的Accept-Language头
  • 有没有被fetch实现自动覆盖的请求头，比如默认的Connection、Host头
• 排查连接复用导致的服务端状态绑定问题
  Node.js的fetch默认会复用同域的TCP连接，甚至会保留服务端基于IP/连接的会话状态。如果你在同一个Node.js进程里，之前请求过同账号下TypeB类型campaign的token接口，服务端可能会把当前连接和IP和之前的TypeB导出类型绑定，哪怕你之后换了TypeA的campaign ID请求，服务端也会直接沿用之前的绑定状态生成对应TypeB的token。验证方式很简单：重启Node.js进程，第一个请求就调用该拿token的接口，看返回的token是不是对应正确的导出类型。
• 校验token参数的拼接正确性
  你当前代码里是手动拼接URL参数accessToken=xxx，要确认这个参数的传递要求：是不是需要做URL编码、参数名是不是和服务端要求的完全一致（比如是不是要写access_token而不是accessToken）。很多老旧API在识别到参数不匹配的时候不会直接报错，而是会默认返回通用的TypeB导出内容，这也是你能正常拿到文件但表头不对的核心原因之一。
• 定位token生成时刻的绑定逻辑
  你已经验证过：只要是Node.js生成的token，不管在哪个环境使用都是错的；只要是其他环境生成的token，不管在哪个环境使用都是对的。这说明token的错配是在生成时刻就固化的，和后续使用token的环境完全无关。只需要把Node.js发的生成token的请求，和API测试工具发的同请求做逐字段的请求报文对比，找到哪怕一个字节的差异，就能触发服务端返回错配的token。

内容的提问来源于stack exchange，提问作者Pierre-Yves Rouillé