Fetch GET请求返回204无内容，但在Chrome开发者工具中返回200正常响应的问题排查
Hey，我来帮你捋捋这个闹心的问题！自己写的Fetch GET请求返回204无内容，但Chrome DevTools里同样的请求却能正常返回200，这种情况十有八九是你代码里的请求和浏览器实际发送的请求存在细节差异，咱们一步步排查：
逐行对比请求头，别放过任何细节
打开Chrome DevTools的Network面板，找到那个成功返回200的请求，把它的所有请求头和你代码里发送的请求头挨个比对。重点盯这些容易踩坑的字段：User-Agent：很多网站会校验这个，代码里的默认UA（比如Node.js环境下node-fetch的UA）和Chrome的UA差得远，很可能被服务器识别为非浏览器请求而返回204Accept：浏览器通常会发送一串多类型的Accept头（比如text/html,application/xhtml+xml,application/json;q=0.9,*/*;q=0.8），如果你的代码只设置了application/json，服务器可能认为你不接受其他类型内容，直接返回无内容Referer：部分站点会校验请求来源，浏览器请求自动带了当前页面的Referer，你代码里没加的话就可能触发拦截- 还有你提到的
x-hsci-auth-token：确认它和DevTools里的完全一致，有没有大小写错误、多余空格或者过期？另外Akamai的Token可能和请求里的Cookie绑定，看看浏览器请求带的所有Cookie，你代码里是不是都带上了？
核对请求URL的每一处细节
确认代码里的URL和浏览器请求的URL完全一致：- 参数的顺序、大小写要完全匹配，有些参数是区分大小写的
- 检查URL的编码情况，比如空格、特殊字符，浏览器会自动处理编码，你代码里如果没做正确编码就会导致请求异常
- 别忽略路径里的斜杠，比如浏览器里是
/api/game-scores，你代码里写成/api/game-scores/（多了末尾斜杠）也可能导致服务器返回不同结果
Cookie和会话关联的校验
Akamai的Edge Authorization Token有时候会和浏览器的会话Cookie绑定，比如类似akamai-session-id这类的标识。你可以把DevTools里请求的所有Cookie都复制到代码的请求头里，再测试一次，看看是不是能返回正常内容。另外跨域场景下，Origin头也很重要，浏览器会自动带上，代码里没设置的话也可能被服务器拒绝。用DevTools生成的Fetch代码直接测试
这是最直接的排查方法：在DevTools的Network面板里找到成功的请求，右键选择Copy->Copy as fetch，把这段代码直接在浏览器控制台或者你的代码环境里运行。如果这段代码能正常返回200，那你就对比这段自动生成的代码和你自己的代码，找出差异点——这能快速定位到问题所在。检查动态生成的请求参数
有些站点的请求会包含动态参数，比如时间戳_t、签名signature等，这些参数是基于当前时间或其他请求信息生成的。如果你的代码用了固定的旧参数，服务器就会判定请求无效，返回204。仔细看DevTools里的请求参数，有没有每次请求都变化的字段，然后在代码里动态生成这些参数。
备注：内容来源于stack exchange，提问作者knotmine
