我最近一直在使用Javascript Fetch API。 据我了解，默认情况下，所有重定向都是透明处理的，最后，我从重定向链中的最后一个调用得到响应。

但是，我可以使用{redirect：'manual'}调用fetch，在这种情况下，它将返回不可用信息的opaqueredirect响应。 来自https://fetch.spec.whatwg.org/#concept-filtered-response-opaque-redirect

An opaque-redirect filtered response
is a filtered response whose type is"opaqueredirect", status is 0, status message is the empty byte sequence, header list is empty, body is null, and trailer is empty.

https://fetch.spec.whatwg.org/#http-fetch表示，如果将重定向设置为"手动"，则响应将变为opaqueredirect：

Switch on request’s redirect mode:
...
- manual
Set response to an opaque-redirect filtered response whose internal response is actualResponse.

该规范还说：

In other words, an opaque filtered response and an opaque-redirect filtered response are nearly indistinguishable from a network error.

考虑到所有这些，为什么在使用Fetch API时将一组重定向到手册？ 在我看来，这似乎毫无用处。 是否有一些有用的用例？

我认为简短的答案是：除非您要使用服务人员代码(例如https://github.com/whatwg/fetch/issues/66所描述的内容)进行操作，否则您永远都不会想要redirect: 'manual'。

更长的答案：

HTML规范似乎要求浏览器在浏览器开始导航到资源时最初将重定向模式设置为manual，然后……(重新)在未设置重定向模式的情况下进行操作？ (在这种情况下，它默认恢复为follow。)我不明白为什么规范中的算法会这样做，但是猜测它一定与处理导航失败的情况有关。无论如何，我相信manual重定向模式在任何规范中都是唯一的用法。

无论如何，Fetch API的设计目的是公开浏览器在提取中使用的所有相同原语，但这并不意味着Web应用程序代码中这些原语总是有很好的用途(与浏览器本身对原语)。

因此，我认为Fetch规范曾经要求即使您可以使用redirect: 'manual'调用API，但浏览器会抛出该错误-我想是因为当时还没有人提出任何合理的理由来设置该API除了浏览器进行导航。

但是由于https://github.com/whatwg/fetch/issues/66，该行为似乎已更改，它描述了一种(角落)情况，其中服务工作者代码中需要redirect: 'manual'。

您可以在Fetch API中进行设置的类似情况，但在Web应用程序代码中实用性很小的情况是mode: 'no-cors'。最初添加它是因为浏览器将其用于某些请求，因此Fetch API公开了它。但这是另一种情况，仅适用于服务人员，其效用受到限制-稍后缓存响应以按原样提供服务，而无需检查响应(mode: 'no-cors'阻止了Web应用程序代码运行)。